What's the Difference?

Are you a Software Developer or a Software Engineer?  There is a difference.  A Developer will write code that fulfills the customers' needs for today.  An Engineer will build a solution that first fulfills the customers' needs for tomorrow, then only second, fulfills their needs for today.  Engineering a solution requires understanding which qualities need to be optimized and applying appropriate engineering principles to best achieve that optimization.  Some qualities are diametrically opposed and require a deep understanding of how they will impact your product and your customers well into the future.  Those decisions, on which qualities to optimize, should always be made by someone who understands the long-term impacts of those decisions — someone who is educated in software engineering.

So how do you optimize your code for maintainability? Extensibility? Or testability?  When building software components, how do you decide which classes to include and which to exclude?  A Software Engineer is expected to know exactly how to optimize each of those qualities and understand the impact of grouping together certain classes, but not others.  Those decisions greatly impact the quality of your code and the quality of your product over time.  It all goes back to understanding your quality model — if you even have one.  In most cases, a software developer gives little attention to any quality model and focuses primarily on delivering to the customer today.  Because as we all know, the customer wanted it yesterday.  But there is a steep price to pay for taking short cuts and delivering too quickly.

What happens when you don't give attention to the maintainability or testability of your code?  You spend too much time and effort struggling to maintain and test your own code than you ever should.  You incur technical debt and your rate of delivery (your lead time) steadily grows longer and longer — until you're spending more time dealing with bad architecture and bad code than you are adding value.

The worst kind of technical debt is when you do not even realize you are incurring it.  It is the worst kind because it will linger in your software, slowing you down with every enhancement and extension you make, and will likely never be fixed.  That is what happens when you do not know your craft.  You introduce technical debt without even knowing.

Our industry changes faster than any other on the planet.  And the rate of change continues to accelerate about every six months.  Being a true software professional demands that you make a substantial effort to continually learn new technologies, frameworks, and patterns for delivering software. 

As DevOps continues to consume our industry the world over, it is no coincidence that “continual learning and experimentation” is the third way of DevOps1.  And yes, it is that important.  Any organization that does not support this culture will waste considerable effort keeping the revolving door spinning as new talent will be a constant requirement to meet business, customer, and market demands.

Whether you are a software developer, engineer, or craftsman, keep yourself relevant — know your craft.