Aug 08 2014
When MojoTech was smaller I spent more time writing code than emails. That ratio has changed over the last few years. Now that I'm now more responsible for business development than software development I spend more time with non-technical business leaders than I used to, including clients.
A common theme I've noticed is how most people tend to lump all software developers into one category. Which makes sense. From an outsiders perspective, writing code is a mysterious process: they've probably heard terms like Programmers, Engineers, Front-End Developers, etc. What’s the difference and why should they care?
Because there are some fundamental differences between the people that will write code for you.
Those differences will directly affect the success of a software development project. Especially if you're like many of our clients, and your software is your business.
I'll use the terms programmer and engineer to label two actors common in the software development world. You could pick other labels--the point here isn't to define the terms--it's to highlight the different approaches to software development that each one takes, and why it matters.
Engineering is the creative application of scientific principles used to plan, build, direct, guide, manage, or work on systems to maintain and improve our daily lives.
-National Society of Professional Engineers
Engineers have acquired a significant amount of training and experience and view their activity as part of a larger, repeatable, inspectable, adaptable process. Engineering requires more thought and more discipline. The primary focus of a programmer is to write code that satisfies a set of requirements.
In a nutshell: Programmers write code, Engineers build software. There’s value in both to be sure.
In reality, most people aren't really choosing, they are taking a leap of faith and assuming the best possible outcome. (Even some of our clients have hired us and then been surprised by the amount of thought put into the development process compared to other programmers they had worked with. They hired us before they understood the value of Engineering. It was a happy surprise.)
For people who do make a conscious decision to work with a programmer over an engineer, they often overestimate their ability to create a successful outcome. Many business leaders know what they want, and are just looking for someone to implement a solution that works. Many default to hiring a programmer. Programmers are more readily available and often less expensive (in the short term). That's fine for some projects (getting a prototype out the door for example), but probably less so than you think.
At the start of a new project you might think you have more of the answers than you truly do. So while it might seem like a programmer is what you need, as the project gets underway and you discover your assumptions were wrong, or a new opportunity arises, your programmer is going to struggle to keep up with you. Your programmer may also make some upfront decisions (Technology Stack, Database Architecture, etc.) that may come back to haunt you.
Let's say your programmer does keep up. Not only have they kept up, you've shipped the first version of your app / product. Most people never ship, so it's hard to say you've made a bad decision. This is probably your best possible outcome.
And yet, many of our clients come to us in this situation. They’ve launched their product and they are still coming to us for help. Why is that?
It's usually because while their programmer was struggling to keep up they were piling up significant code debt that will have to be paid off in the future.
You don't need to understand the code to see the warning signs of code debt. Here are some examples:
It's around this time people start to learn about the difference between a programmer and an engineer. This is a much more costly time to learn though. Had you hired an engineer from the start you would have paid more. Probably 25% more on average. But now you're faced with a difficult business decision. When do I pay down this technical debt I've accrued? It's a hard decision because it usually means halting any new visible progress and investing far more than that 25% premium just to arrive at the place you thought you were.
So, do you need an engineer? Maybe not, but there’s a good chance you’ll wish you had one the further down the road you get.
~ Nick Kishfy @kishfy
Interested in working with MojoTech? Drop us a line.