In a previous post (), I commented on Joel's notion that duct tape programmers are not a bad thing. In review, a duct tape programmer slaps enough spaghetti code on the wall to make the solution "work".

I use work in quotations because the definition is highly dependent on time. At first glace, an entirely static website "works". However, it stops working the moment the user wants control over the content. There are numerous reasons why Joel is mostly wrong on this one and it all comes down to risk and stakeholders and of late, I have come to painfully experience many of them.

If the entire company is riding on "something" that must be delivered in a very short time frame, then clearly the cost of maintenance is obviated by the need to get the business. In this one case, the need in the short run, more than overwhelms the costs in the long run. However, in my experience, almost no projects fit into this category.

For most projects, it comes down to a question of risk assessment: "What are the long term maintenance costs in comparison to a bad short time solution?" For sites that can be entirely re-written in a week, the long term cost of spaghetti is low. If another hero developer walks in the door and exclaims that the entire site should be posted on The Daily WTF, he/she can rewrite the entire thing for little cost. If the site is large and complicated, then the long term maintenance implications are higher. Someone has to be able to read the original developer's code, make sense of it and be able to adjust it. If the site is a multi-tenant application such as what I'm building now, the maintenance implications even in the short term can be catastrophic.

With respect to stakeholders, most consultant developers have a habit of discounting *all* of the stakeholders. One of the key stakeholders are the other developers that have to maintain the system. That said, it is not the case that all stakeholders have the same value in a given solution. In a tiny solution or a non-critical off-the-shelf solution, developers have little or no stake in the solution. However, in a large, highly integrated solution or a multi-tenant solution, developers have a *huge* stake in the solution. Hard to maintain systems can increase maintainance cost exponentially. In multi-tenant solutions, quality of code makes a substantial difference in maintainance and thus cost and thus profit.

So, that's where I'm at today: having to fix a "professional" duct tape programming organization's evil spawn. Worse than that, there is there no penalty for such a situation to the original developers. They keep making sewage and moving on before any can find the smell.

In a relatively recent post by Joel, he pines poetic about "duct tape" programmers that "just get stuff done." 

All business endeavors come down to cost-benefit analysis. Writing code with bailing wire and 3-in-1 oil is no different. The cost of writing spaghetti code is always in the maintenance and reporting not in the initial release. How many customers will have this code? If the application is purely one off for one installation point or one customer and will never be reported against, then the benefit of releasing "something" more than covers the cost. How often does that type of project come along: one installation point and/or one customer, zero maintenance responsibility, zero reporting?

Writing code that is difficult to maintain adds orders of magnitude to the cost. If there are many installation points, then the cost rises exponentially with the number of installations.

In my experience, the "just get it done" developers generally never look to the future. They never ask questions about maintenance or reporting. Typically, they swoop in, write the magic widget with no care about code quality or maintainability, bask in the warmth of hero worship for "getting it done" and move on before anyone has discovered the cluster f- they created. If your company is really unlucky, "the day" comes when it is realized that said duct tape developers' solution only "looked" right but in reality had several critical flaws that bring down the company. I have been a witness to this exact scenario (thankfully, it wasn't my code) and it wasn't pretty.

In my experience, I find that people that just want "get it done" developers do not account for all the things that actually need to be done.

Developers should write their code with the assumption of a handoff. In other words, developers should write any and all code with the assumption that someone else will need to modify and support that code in the future. Sadly most developers do not realize the merits of this goal until they are required to work on spaghetti code which was clearly not written with a handoff in mind. Perhaps the worst task given to a developer is to support a pooly written application or site.

One the rarest and yet most valuable attributes a developer can possess is knowledge about all systems involved in their solutions. Most developers unfortunately, think they posses such knowledge but rarely do.

Let’s take the case of a simple ASP.NET website. To get such a site to the web, a developer must obviously know ASP.NET and some language to code therein. However, they should also know of a means to push their files (FTP); how to configure their site and/or virtual directories; how to setup application pools; how to setup permissions; the credentials under which sites normally run and if different under which their own must run. Then there a host of other technologies such as DNS and routing not to mention load balancing and how it might affect their site. Saying that this is a simple ASP.NET site implies that there is no data store behind the site which adds a host of other applications and technologies that the developer should know.

In short, developers should strive to know about every system from the end user’s software through to the server that touches or affects their code.