Developers Are Not Plug and Play

Plug and Play It never ceases to amaze me how short sighted management at many companies can be with software developers. Jeremy Miller mentions a discussion he had at the Austion Code Camp in which several developers were really unhappy with their work situations for very legitimate reasons.

I am reading a book called Beyond Software Architecture and just finished a short section on Design Debt. I’ve read and written on this topic before, but I focused on the cost to change code that is in debt. Luke Hohmann takes it further, noting that by not paying off that debt, a developer’s attention to quality is deadened. If the management does’t care and won’t allot the necessary time, what can we do? Not only that, allowing the code to remain and incur more design debt chips away at developer morale.

As Jeremy points out, there are two solutions, try and be a leader, institute good practices, and convince management to allocate the time, or move on to greener pastures.

And you know what?

Management doesn’t care. Many of them see developers as plug-and-play. We’ll just get another one. Ignoring the cost to recruit and hire a new developer, they’d rather just plug in a new developer than make difficult systemic changes. Changes that would ultimately lead to the benefit of the bottom line, but does not do so immediately in a manner they can show off to their shareholders, bosses, whomever.

So what is the solution? Unfortunately I do not have much more to offer than what Jeremy points out. Personally, I make all efforts to refuse to compromise on certain practices in the first place. I am not always successful, but I have worked in high pressure situations where I simply refused to lower my attention to quality and still took the time to write unit tests and spend time refactoring. My successor at one job even IM’d me out of the blue to congratulate me on the quality of code I wrote in such a chaotic situation. That felt pretty good.

And the funny thing is, it did take a bit longer to reach code complete, but I do not think the overall time to release was extended. “Code Complete” usually meant to now find and fix all the major bugs introduced from rushing it in the first place.

Comments

6 responses

Carlos M Perez • March 10th, 2006
You've nailed it, Phil. And in Spain (at least around the body shops I've worked in) that situation, that kind of thinking is everywhere. In every company, in every manager, even on most developers. Why bother?, they seem to think. We never have the time not only to refine and refactor our code (if it works, don't touch it!), but simply to do a proper analysis before coding. It's sad, because in the end it all just adds to the woes of the two groups of people with the least to blame: customers and legacy coders.

Carlos M Perez • March 10th, 2006
Nice Live Comment feature, by the way. Keep up the good work with SubText.

Jason • March 10th, 2006
It's as hard to generalize about "management" as it is about "developers," but I've worked with my fair share of developers who were incapable of communicating the value of reducing technical debt and the long-term cost of not doing so.
It's certainly not easy, but unless you've got exceptionally good management, you're always going to have to advocate for things like that.
I'd also agree with you that the best way to handle the whole situation is to not go into debt in the first place.

Haacked • March 10th, 2006
You make a good point. I don't mean this for ALL managers (I was and am one too in a sense), but it's a common thread among executives. And I don't do enough to put some onus on developers to communicate this.
As for not going into debt in the first place, that would be ideal in an ideal world, but not even I advocate that as being possible. Sometimes you have to incur a bit of debt because you have to deliver.
But like a housing loan, that debt is a strategic investment. The problem lies in not paying it back, but instead paying your mortgage payments with your credit card.

Haacked • March 10th, 2006
Carlos, the next version of Subtext will have an improvement to make it really easy to add live comment preview to any blog.

Mike Burroughs • March 13th, 2006
In the role of VP Development for a software company, I am at the same time a developer (yes I actually product production code, with unit tests :-)) and an executive. To be honest this post points out what I believe in general to be the primary problem at most places: the us vs. them attitude.
Non-technical management generally doesn't understand the concepts of design debt, agile development, unit testing, SOA, OOA, SAAS etc. etc. etc.
Technical developers generally have no clue as to the breadth of issues that must come into play when making decisions in a company of any size.
And isn't it fun putting both groups in a room and watching them attempt to communicate. Perhaps I am blessed with an organization that saw fit to have a CTO (me) who is willing to translate technical arguments into business language and justify business decisions in non-IRS/SEC/FASB language. I spend hours a week on these tasks and there are days when I'd rather ram my head through the wall.
A case in point was today's discussion: The revenue recognition implications of delivering our software using an SaaS model. The implications to the bottom line (and thus our ability to pay the developers) is significantly impacted by this issue. There are technical decisions that are driven by the decision about a deployment model that are impacted by this issue. And I will admit that this time the developers had it wrong, and they were every bit as pig headed about accepting it as they generally accuse management of being.
Most developers and development management make very compelling technical arguments for their software development process of choice. What most don't do is equate that to the real business driver, the bottom line. To be fair, most executive/financial managers don't ask for this information either. Both sides seem more interested in standing on the other side of the divide and pitching a fit, than actually trying to communicate in terms that the other group can comprehend.