How

If you Google “engineering”, you’ll probably get the following definition:

The branch of science and technology concerned with the design, building, and use of engines, machines, and structures.

• The work done by, or the occupation of, an engineer.
• The action of working artfully to bring something about.

I particularly like the second part: the action of working artfully to bring something about.

As an engineer, we start with the How. In fact, we’re kind of obsessed with it:

• How do you perform your testing?

• How do you structure your software?

• How do you design your system?

• How do you express your requirements?

Which, of course, makes sense. Being an engineer is all about building something; if you do a crappy job of that, you’re not going to be a good engineer. And there’s a lot of good in honing your craft, becoming really, really good at software implementation. My favorite programming book is still Code Complete, and for good reason.

At some point, you’re very likely to be working on a software project when suddenly the project manager starts ratcheting up the pressure. Maybe a deadline slipped. Maybe there was no deadline but stakeholders are starting to get frustrated with the lack of a delivery. Maybe the software that was delivered didn’t contain nearly everything they thought they would get.

And that leads us to the next question.

What

As in, what the heck are we building anyway?

Time is the only finite resource. Every second of every day is a second you’re never going to get back. As I’m writing this, I’m choosing to write this instead of doing something else. In my case, it’s watching TV, so this is time well spent. But I could be working. I could be starting a side project. I could be reading something that furthers my skills, or learning a new language.

But I prioritized writing this (for some reason or another. Humans are strange). And that prioritization is immensely important in software.

A software project never really ends until the business producing it decides to stop selling it; even then, it can live on in some form. There will always be new bugs, features, improvements, refactorings, and more. The work to be done will always exceed the resources available. The order in which you do things thus greatly determines the likelihood of project success. Prioritization, more so than time estimates, requirements analysis, or anything else in the project management sphere of control determines the life or death of a software project.

As an engineer, you should care about this. No one cares how well you crafted a new feature if it wasn’t that important. And having your work be devalued sucks.

So let’s say we’ve got prioritization taken care of. We have a well groomed backlog, so we’re presumably building the right things in the right order. Great.

And then it gets time to launch, and you’re told that no one wants your software. The business doesn’t know how to sell it, or the business folks have realized that we can’t make sufficient money given the cost of customer acquisition. Perhaps the business doesn’t understand the sales model. Maybe the software doesn’t really solve a problem a customer is willing to pay for. Maybe the business thought they knew what the customer wanted, and no one actually confirmed it.

Or maybe there never was a customer.

When this happens, you’ll feel burned. And that leads us to the next question.

Why

Why are we building this thing at all?

That is:

• What problem are we solving?
• Is this a problem that we can charge money for?
• Does the customer who has this problem want to pay for a solution?
• How do we find these customers?
• How do we differentiate in the market?
• Can we survive as a business selling this?

Again: time is the most valuable resource. It’s one thing to save time by prioritizing your backlog, it’s another to make sure that you have the right backlog in the first place.

Some may argue that others get to make these decisions, and so an engineer doesn’t really need to know the Why or the What. “Focus on the How and stay in your lane.” And if you’re content with having your life wasted, you can do that. But great engineers don’t want to waste their lives building things that don’t matter. A great engineer will help the business course correct throughout the life of a project and make sure that the business’s resources are being allocated and spent in the best manner possible. A great engineer will have a valid opinion and a pertinent voice in the decision making process of why are we building this thing.

A novice engineer cares about the How.

A good engineer focuses on the What.

A great engineer understands the Why.

I wrote a rather lengthy blog post for the Asterisk Blog about the recent RTP related security vulnerabilities in Asterisk. I won’t go into more detail here than I did there, but given that there was a public disclosure of flaws in the first security release that occurred without warning to the project team, things were not as smooth as we would have liked.

To find vulnerabilities, you have to build tools and perform actions that in a non-controlled environment would clearly be malicious. That’s not bad in and of itself; what you do with those tools and the information you gain from them determines your ethical bent.

If you look at some of the major vulnerabilities, you can see that things have gone a bit “commercial”. Vulnerabilities now get names, marketing sites, hell - even stickers. The researchers who found the RTP vulnerability in Asterisk quickly piggy-backed on this, dubbing the vulnerability “RTPBleed”.

I get that researchers need to get paid, and marketing certainly is important for those who are trying to run a business. But as a business, do you owe the projects and products that you find vulnerabilities in anything? Or do you only owe your customers who paid you to find the vulnerabilities? How do those conflicts get resolved?

I sure don’t know, and I doubt I have a good, well formed opinion on it. But there’s something slightly sour when websites and Github projects go up quickly, and the developers responsible for delivering the working software are unaware of the full impact of the vulnerability they supposedly fixed.