Sharp Learning Curve

Craftsmanship and Delivery

I feel very strongly about this issue based on personal experience, education and just plain fear that some important points are getting missed. My frustration is definitely going to show in this post, so yes, it’s “ranty”.

TL;DR

Speed over quality only makes sense if you work in the fast food industry. Software development isn’t strictly engineering, math or art; the medium we work is too tractable for it to be limited to only aspects of any single fields. It is a unique discipline that requires knowledge and interest in many fields to achieve mastery. Craftsmanship, to me, is about acknowledging these elements of software development and how they are each instrumental in delivering real value to the customer that provides a return worthy of the investment made in our ability. In my opinion, far too much time is spent trying to reduce the many-faceted complexity of good development to some myopic name, phrase or platitude. Software development is neither simple nor for the light of heart. If you are either, flee. Here be dragons.

Anecdotally…

I’ll say that I know of at least two companies that have become irrelevant in their industry because they got stuck with and kept an awful code base. I know of one that collapsed largely due to a very expensive, awful pile of crap that was built under a “just ship it!” team; when the dust settled on that project, customers using the system suffered real and true harm. In one case, the “delivery focused” organization took an awful code base and spent 3 years trying to make it fit for market. Initially they had a 3 month plan for how they could “make it just good enough”.

Requisite Knowledge

I’ve been writing software professionally for almost 10 years now. I’m one class away from an MBA in Technology Management and my undergrad was in MIS (a business/tech degree). Economics, finance and managerial accounting are no strangers to me. All this to say; I actually have a requisite knowledge to add at least some weight to my opinions.

The Aftermath of Astronauts

I think some of the attention to delivery timelines has come from several software projects getting burned due to the time it took to write them only to find the company was too late to market, the technology had already gone stale, or the design that was so painstakingly implemented is now obsolete. I think that chasing after the “new” tech is definitely bad and I’ve been guilty of this in some cases. My personal lesson: favor open standards over vendor flashiness, learn from other systems with similar technical footprints, focus on simplicity over technical “coolness” and only accept complexity where warranted. Those are all safe take-aways. I think the knee-jerk reaction against long time-lines fails to really analyze the wreckage.

The Experts Pushing “Just ship it”

I get it. Delivery matters. Here’s the problem: you’re so good at software development, you care too much to deliver junk and to you, delivering quality solutions isn’t the minefield it is for the average developer out there. You’ve probably been on projects where technical issues ate up too much time. I’ve seen several projects spin their wheels because of the technologies chosen to implement the solution.

All that to say, when average developers who admire and look up to you hear you say, “just ship it”, that’s all they hear. How about change your message to “deliver value”.

The Legacy of GET ‘ER DUUUUUUUN!

There are a lot of developers that try to disguise incompetence or obsolescence behind rhetoric about how they’re just trying to serve the customer’s best interest. The customer doesn’t want a half-assed hacked together solution that they will have to pay someone like me to come in and fix (I charge more to clean up messes because I can actually deliver). When code is slapped together as quickly as it can be copied out of MSDN articles and StackOverflow answers, something has been shipped, but it’s more like a time-bomb than value.

I’ve worked with, cleaned up after and outlasted too many of these kinds of developers to have any patience left with an over-emphasis on shipping.

The False Dichotomy

If it’s not apparent yet, I don’t believe that a slavish mindset to either extreme is tenable. This is just part of the reason I’m so frustrated by this kind of debate. Your customer wants you to deliver quickly but they need you to deliver value. The challenge is honestly in the communication. If you have the right people on the project, those individuals can remind the customer of why it’s taking longer than yesterday to deliver value. You have to deliver quality.

Sunk Cost Fallacy

The sunk cost fallacy in general is insisting that something is worth $X because that’s what you’ve spent on it. I’ve seen a lot of individuals make this mistake without consciously realizing that’s what they’re doing. In reality, it doesn’t matter what you spent, it only matters what value the thing can provide. Most managers make this mistake presented with a rewrite vs. duct tape choice: “we’ve already spent 2 years and 2 million developing this application, it’s too expensive to start over”.

Software Projects of Significance are Capital Investments

Software projects of any significant size are a capital investment/project. In companies run by leadership with a clue, this kind of investment is tracked and measured for return. In companies that get burned with systems that continuously fall over or are too expensive to maintain or upgrade, leadership will realize, “I could invest this money on the market and see a better return”. The system exists to provide a return. If it doesn’t it’s a failure.

Deliver Quality

If the system in question exists as part of the company’s core competency/value proposition, it can’t both be a raving success and a flaming pile of crap. This is a point that really shouldn’t get argument but I’ve been surprised by the number of individuals who try to say that time to market is more important than quality. Right. Time to market is important, but what you bring to market is equally if not more important. User satisfaction cannot be faked; they’re not going to like a failed mess because it was fast.

Comments