The Duct Tape Programmer

theodp writes "Joel Spolsky sings the praises of The Duct Tape Programmer, who delivers programming teams from the evil of 'architecture astronauts' who might otherwise derail a project with their faddish programming craziness. The say-no-to-over-engineering attitude of the Duct Tape Programmer stems not from orneriness, but from the realization that even a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab where you're endlessly polishing the damn thing. Like Steve Jobs, Duct Tape Programmers firmly believe that Real Artists Ship."

Comments

False dichotomy

[ciggieposeur]

I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.

Architecture astronauts

[Aceticon]

I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.

The typical evolution towards wisdom in Software Engineering goes like this (simplified):

• Starting by making small programs or programs supposed to be used only once (i.e. school assignments)
• Transition 1: Discovery of code reusability, the problems with copy & paste coding and how using methods lets you partition your code into more easy to understand blocks - this is when one transitions beyond junior developer
• Transition 2: Discovery of the concept of software design and how it makes for more adaptable code which is easier to understand and how it helps main complexity small as the size of the program increases - this is when one transitions into junior designer
• Transition 3: Discover that there is such thing as too much design. That over-designing decreases maintenability, makes the code harder to understand by others and by oneself in the future. That the flexibility that the real world will require from the code will rarely match one's initial idea of what should be made flexible during design and that trying to create a top-to-bottom design that covers all eventualities actually results in an inflexible system. Above all, discovery of the value of the KISS approach: don't design/implement a specific something now because you think you will need it later, it is often easier to do it then if you do actually need it and you probably won't need it and are just making for big code instead of useful code. At the same time discover that newer isn't always better when it comes to software tools, languages and frameworks and that coolness and hype are really bad things to focus in when choosing something to use in an professional IT project - this is how you get medior designers and senior developers
• Transition 4: Discover that creating software is actually a process not an act. That a lot of things serve as feed-ins to the actual design and development of software and a lot of things feed out from it. That software isn't just made, it lives, evolves and gets changed. That making an application is easy (no mater how big and complex) and making the right application which does what's need in the right way for the users of the application is what's hard. That the quality of your feed-ins (requirements, analysis, time, people and all manner of preparations) is much more relevant to the success of a project than the code or the design. That over the long run, the true quality of the code and design is measured by how easy it is to regression test, maintain, support, extend and by how fast new designers/developers can pick up the code (which are some of the feed outs) - this is how you get senior designers and technical analysts.
• Transition 5: Discover that the applications your develop are part of an ecosystem. That software talks to software that talks to software. That many applications need to do many of the same things, only in slightly different ways. That standardizing (up to a level) things like certain kinds of exchange of information between applications or the kind of libraries used for certain common functional areas (such as multi-system logging, single-sign-on, messaging) will make for increased overall productivity and maintenability (develop and maintain a single implementation for each and distribute it as a library). Discover that standardizing on a reduced number of mature programming languages makes it easier to find people to work with them and move people around to different projects and systems - this is how you get technical architects

At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.

I would hardly call a junior designer type "architect".