Coders vs Programmers: Big Ball of Mud

In a recent post, Scott Bellware rants about the Microsoft developer personas Mort, Elvis, and Einstein and the software development methodologies and tools Microsoft promotes through them; and also throws in a few punches at Rocky Lhotka's opinions on TDD and software development.

The post has spurred a lot of comments, one of them from a "programmer" that feels that all these efforts to define better methodologies and to build better tools to support them, is the search for the holy grail and, in fact, the real problem of the software industry:

"Some people actually have a life and the holy grail of software engineering is not it. Go home, relax, get a life. Let the rest of us go to work, do our thing and go back to living. Working a 40hr/wk job with real deadlines and with a real family life or life that has it own requirements and demands quite honestly doesn't leave much time to learn all this new methodolgy. Especially when it changes so quickly.

That my friend, is the reason why the industry is the way it is. PLAIN AND SIMPLE! Perhaps if we were all workaholics that had no other ambitions in life but to reach the holy grail of software development nirvana, then things may be the way you want. Your wishing against reality."

I have heard this kind of arguing before, it is not uncommon. In fact, it is part of a pattern called the Big Ball of Mud. I really recommend reading the whole BBoM article, it even contains a finding to support the "get-a-life/workaholic/nirvana/against reality" arguments above:

"it is inevitable that 'on average, average organizations will have average people'. One reason for the popularity and success of BIG BALL OF MUD approaches might be that this appoach doesn't require a hyperproductive virtuoso architect at every keyboard."

This leads me to my own little quest at work these days:

Coders vs Programmers.

A lot of developers are campers inside big companies, hiding in their cozy foxholes, doing their thing, blaming the everchanging tools and methodologies (and requirements) for not being able to produce anything but a BBoM. This kind of (demotivated) developer is what I call a "coder" (see also the related "code monkey - type 1").

Perhaps if they could make their code just a little better by using some methodology, they could go home knowing that their solution is built to last, and in addition, be proud of their workmanship ("Software Craftsman"). There is no conflict between having a life, working 40 hours a week, and producing quality code.

The real problem of the software industry is that there are way too many coders, and too few programmers. Programming is more than just emitting code that compiles and works; I state that coders produce BBoM even when not constrained by time or money.

I believe that the whole software quality issue revolves around being genuinely interested in software design issues, striving to be an architect rather than a "swamp guide" (from BBoM). The book "Zen and the Art of Motorcycle Maintenance" by Robert M.Pirzig contains a lot of good thoughts about quality, and "pride of workmanship" is a central theme in the book. I recommend reading ZAMM, it will give you some philosophical insight to the topics discussed in the BBoM article.