Maintainable Programmers
By Aristotle Pagaltzis under Then they laugh at you... on 30. December 2005I thought it unfortunate that the controversy kicked up by a few (now retracted) passages in Brian Fioca’s article about WASP detracted from a proper discussion of the article’s real flaw. I addressed the controversial, less interesting sentiments in comment over there, but wanted to take a few moments for a longer commentary. It took a while, but here we go.
The true failing in that article is a terminal case of corporate-management world view. Let me quote a little out of order to highlight this:
Sure, you can write spagetti code in PHP 5, but if you have a well designed framework that keeps PHP code outside of your HTML and in tightly structured classes, you’re more likely to end up with code that looks and works and feels like Java.
The implication appears to be that anyone in the real world, if only they’re using Java, writes well structured and maintainable code.
I think the real world has a few surprises in store for people who think that way. As the saying goes, real programmers can write Fortran in any language.
Deemed “hacker” languages, scripting languages can be quick to write, but since they do not have many of the advanced features of compiled languages like C++ and Java, they have been prone to lax design practices, leading to code that isn’t efficient, stable, or maintainable enough for large solutions. With the correct mindset and help from structured frameworks like WASP, this no longer has to be the case.
This claim is a crock. PHP has a very low barrier to entry; consequently, a lot of eye-wateringly bad programmers are writing code in it; hence, a lot of code written in PHP is awful. This is arguably a good thing: a lot of people who have small needs are empowered to meet them on their own despite having little skill, which would never happen if Java were the only option available.
To conclude that if these programmers did learn Java, they would suddenly turn out maintainable code, or that if a good programmer changed camps from Java to PHP, the quality of his code would suddenly degrade, is fallacious.
Again, you can write pretzel logic in any language.
Until recently, platforms like Java were more likely to provide a stable, proven foundation to design and build well designed code, however by their nature they introduce a level of complexity that takes extra time to overcome.
The entire “more likely” clause is a myth, perpetuated by a middle management population that has absolutely no clue whatsoever what makes code good.
Using scripting languages like PHP tended to produce code in a faster time frame, but it was often impossible to maintain the architectural integrity necessary for building maintainable, extendable applications.
This is true – in an extremely local sense.
The overall design of large Java systems will tend to be more convoluted than that of almost any system written in a dynamic language, simply because the contortions forced by Java require larger overall designs.
Java buries the intention of code under a thick layer of implementation details and typing bureaucracy. Programmers are drilled to execute the requisite gruntwork in repeatable, predictable ways. Moreover, doing so conditions them to design their own system to cater to these reflexes. A maintainance programmer who comes in later will therefore easily be able to make changes to the mortar of an application. Unfortunately, that does not ensure good high-level designs nor does it translate to easy refactoring of convoluted architecture.
Dynamic languages abstract away huge swathes of gruntwork and require less structure. This means small systems have small implementations, which directly translates to better maintainability. The price is a loss of exemplary structure and of conditioning, which requires better innate architectural skills and stronger discipline when building larger designs; neither are strong points of the average programmer. However, designs in such languages aren’t frequently large, because the language does not require large architecture for modestly sized systems – which the majority are.
I have seen as many examples of truly terrible designs in Java as I have seen examples of completely unreadable code in Perl. Maintenance problems may manifest in apparently different ways, but their cost does not degrade appreciably when they afflict a system written in a “more maintainable” language. The only objectively measurable difference is in the amount of required code.
Why would you want to stick with PHP even in situations when you can use Python, Ruby, or anything else?
Simple. Because it’s cheaper to hire programmers that can write code in PHP. And if you have a good technical lead and a well implemented framework, your cheap programmers are going to pick it up and run and write good (and maybe even less) code.
(Brian writes this in a response in the comments, not in the article.)
This is a fear-based middle-management hiring strategy. Good developers know that “cheap programmers” will never hit the high notes. You can hire 100,000 code monkeys and they will never produce the same quality as 5 stellar programmers.
All these quotations are pervaded by a disregard for the fact that programmers are craftsmen; for the fact that that the language, framework, and whatever else they use in the course of their work is a tool. Good tools matter, but the stated opinions read as if the programming language is the principal factor in the quality of the result, when the truth is that it’s the programmers who ultimately matter.
If you hire good programmers, maintainability won’t intrinsically be affected by whether your in-house software development has standardised on Java, PHP, Perl, Ruby, Lisp, Smalltalk, Haskell, or Self. Good programmers can appreciate and can create good design regardless of language, and they can absorb a new language easily enough. Or as Joel Spolsky says:
I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.
But whether your system is written in Java or an exotic programming language, every single programmer you hire will have to get acquainted with its architecture – which is hence the major factor in its maintainability. Comparatively, the chosen language is barely more than a neglibility, assuming it has a good impendance match with the type of application being written.
In thinking about this issue, I am in fact tempted to recommend that you hire programmers who are unfamiliar with the language your system is written in – because if they still struggle with the basics of a new language after a month, you might want to reconsider their future with your company. But that may be too bold a claim. Even if, in lesser form, it has been made before.
The bottom line is that you need people capable of producing a clean, flexible and only-as-complex-as-necessary architecture for the problem they were tasked with solving. And you won’t get that from an army of code monkeys, even if you hire 1,000,000 of them.
Kevin Smith:
Well said.
My only small disagreement/clarification (and it regards the quote from Joel) would be that developers who have never done OO before often have a difficult time adjusting to the OO paradigm. I suppose these days, it’s rare to find someone who hasn’t at least been exposed to OO, but a decade ago, it was very common.
For any OO project, I would want some evidence that the candidate was comfortable with OO. Likewise, if the project used a functional language, I would want functional experience.
comment at 30. December 2005
Brian Fioca:
Your points are actually good ones, and your conclusion is in agreement with what I personally believe to be true.
I’d like to say that I realize this isn’t a personal attack, and I appreciate the criticism. However, the article was originally written for an audience stuck in fear of scripting languages such as PHP for no actual reason other than they heard it was bad. This is the reason it has a “corporate-management world view.”
I would argue that the typical audience of lesscode.org understands most of the things you point out above, but if you were to try to explain them on their own to someone who is for some reason stubbornly avoiding any real analysis of dynamic language use for their applications, you wouldn’t get very far. Hence, the intermediate step.
I really wrote the article for someone like me. I had a similar mindframe 2 years ago, but have since seen the error of my ways. My context (and in my experience, many others’) was the world of Java, and my fallacy was that, while it is certainly possible to write bad code in Java, it is most probable that one would write bad code in PHP, including myself. This turned out to be untrue. It was a surprise to me. I wanted to convince people in my previous situation what I learned. I wrote the article.
So, even though you seem to have taken apart my article, I want to thank you for furthering my original goals.
comment at 30. December 2005
Brian Fioca:
Well, I was going to leave this to someone else to say, but nobody has yet and it’s bothering me.
What is intrinsically wrong with the corporate management world view? Those people pay my salary. In the real world, it’s those people you have to convince.
Certainly the best programmers are much better than the monkeys. The main problems are there’s no easy way to judge them, and you can’t hit deadlines with artists. So in the real world the monkeys work. So the best option might be to give them a good tool to work with.
comment at 30. December 2005
Tony Wright:
I’d also throw in a response to the assault on Brian’s original point:
“Why would you want to stick with PHP even in situations when you can use Python, Ruby, or anything else?
Simple. Because it’s cheaper to hire programmers that can write code in PHP. And if you have a good technical lead and a well implemented framework, your cheap programmers are going to pick it up and run and write good (and maybe even less) code.”
Aristotle gives a response that effectively says “Well, sure, but you get what you pay for”. I think that’s totally missing the point. Cheaper, in this case, means less expensive and more plentiful (and thus cheaper to FIND from an HR standpoint)– not lower quality. In the supply/demand world, the supply of PHP programmers is very high (the demand is pretty high too, but you can find a PHP guy on every street corner). A badass senior PHP coder can be less expensive to find and hire than a similarly badass Python programmer.
Comparing 5 great coders to 1,000,000 “codemonkeys” is silly. Instead, compare the 5 great coders to 1 great coder (as tech lead) with 4 solid mid-level/junior programmers. Your chance of staffing up with ONLY great coders is pretty slim. So in the business reality where you have to hire some mid-level and junior-level coders (cause that’s all you can find/afford), what will help you succeed? Business systems and coding frameworks will!
Aristotle’s argument is the equivalent of saying “Why do you need Ruby on Rails? You don’t need any sort of framework. Just get really smart and experienced coders and they’ll create great code in Ruby – without the ‘rails’”.
What makes Ruby on Rails (and WASP) so amazing is that a “codemonkey” (though I’d prefer the moniker of “coders-who-don’t-consider-themselves-artists” or CWDCTA) can create a good app with good code, whereas the SAME codemonkey probably couldn’t or wouldn’t WITHOUT the framwork.
System and process engineering in business WINS over hiring geniuses and turning them loose almost every single time. The goal of a framework like WASP or RoR is to allow non-genius programmers to aim higher and create better code.
It’s no secret that around 80% of non-franchise businesses fail or close within their first decade. Franchises, on the other hand, enjoy an 85% success rate in the same time frame. The difference isn’t that the franchise businesses hire the absolute elite people in their field (usually the opposite is true). The different is that there is a system and framework that allows average people to produce above-average work (yet still command only an average salary).
comment at 30. December 2005
Ryan Tomayko:
Brian said:
I think the issue is more about how do you convince them? It’s fairly easy to buddy up to higher level IT people by feeding them buzzwords and playing off of traditional misunderstandings about what works and what doesn’t in IT. For example, let’s suppose I walk into my manager’s office and she tells me she wants “SOA”. I look down and notice that “SOA” is mentioned on the covers of various tech rags littering her desk. Let’s also suppose that I think 90% of what the tech rags are prescribing for “SOA” is wrong, misleading, promising too much, not practical, laden with issues, etc. What do I do? I can take the low road and say, “Okay, SOA it is — no problems,” and bullshit my way through 6-9 months of development that will ultimately be a failure for myself, my team, and the company as a whole. Or, I could put my reservations on the table and expect the decision maker to consider them along with everything else she’s hearing. I don’t have any hard data on this but I can only assume that the first scenario occurs much more often because there’s a lot of very obviously bad technical decisions being made everywhere.
The “million monkeys typing in PHP” falacy strikes me as exactly one of these situations and I think that’s all Aristotle was pointing out. It falls into the “nine women can make a baby in one month” class of misunderstandings that higher level IT people seem so prone to fall for. Lower level technical people that understand these things to be folly can move the situation in one of two ways:
Leave the misunderstanding in place as leverage. In the SOA case, my job is signifcantly easier if I don’t have to sell the concept — the tech rags have already sold the manager — all I have to do is accept the job and start building stuff. And when it fails, it’s not like the whole SOA thing was my idea. In the million monkeys typing case, leaving this misunderstanding on the table provides an artificial selling point for the PHP framework, even though it might not be “exactly true”
Attempt to educate the higher level person about the issue so that they can make an informed decision.
1 is dishonest and destroys the reputation of technical experts over time (as it has been for some time). #2 would be great but many technical experts are not brought to the table until a decision is already made (this is a result of #1).
comment at 30. December 2005
Brian Fioca:
I think Ryan has identified a great point.
There really is a significant disconnect between the audience of this site and the audience of say, CTO magazine. It’s easy (and, financially rewarding) to write articles in those magazines that focus on buzz words and have little technical accountability. It’s also easy to placate the readers of those magazines like Ryan mentions in way 1. I’m sure there’s enough material here to write an entirely new article.
My colleague reminded me that Kuhn’s Structure of Scientific Revolutions appears to apply here. It seems to me that what’s been going on as of late is an attempt at a paradigm shift in programming technology. Whenever such an event occurs, the natural position of the proponents of the previous paradigm is one of resistance and denial. It often becomes necessary for a revolution to occur in these situations. To say that subversive interjections of a new paradigm into the world of the old guard corporate world is dishonest may be factually true, but it might also be necessary to some extent in order to achieve the shift.
I admit this argument might be a bit of a hyperbole… but I find it interesting. I happen to like revolutions. :) I also like to think part of the purpose of this site is to push this new paradigm into prominence.
comment at 30. December 2005
Mark:
I love the phrase “subversive interjections”, as it reminds me of an anecdote about Subversion (no pun intended). A friend of mine decided, all on his own, to start using Subversion for source control of a small project he was developing at work. The project was officially sanctioned, but it was small enough that there was never any discussion of source control. Inevitably, someone else needed to get access to some of the code, so he calmly pointed them to the subversion repository and a quick half-page tutorial he’d written on the departmental intranet (which was run by MediaWiki, another subversive interjection of his). The newly-introduced-to-Subversion developer immediately fell in love with Subversion, which wouldn’t be difficult since I believe they were using ClearCase on other projects.
When the time came to start another project, the other developer quietly set up a Subversion repository before anyone had a chance to complain, and pointed the other developers to the wiki page that explained how to check code in and out. All the other developers loved it, and so it became the de facto (but never officially sanctioned) revision control system.
This further reminds me of polls circa 2001 in which the vast majority of Fortune 500 CTOs mistakenly believed that they were not using Linux.
comment at 30. December 2005
warpedvisions.org » Blog Archive » Link: Maintainable Programmers:
[…] December 30th, 2005 in Links Maintainable Programmers. Planning maintainability and reuse are the most difficult design problems I know of. A juicy quote: […]
pingback at 30. December 2005
Bill de hOra:
“Or, I could put my reservations on the table and expect the decision maker to consider them along with everything else she’s hearing.”
Absolutely. Start with “I think we need to consider SOA in the context of…”, followed at some point by “..you seem quite convinced; what are you thoughts on…”, closed off by ideally “..actually we do something along these lines” (never say “yeah, we already do that”).
If a term like “SOA” can mean whatever you want it to mean, adoption is not neccessarily a problem. In other words, buzzword bingo can be your friend too.
comment at 30. December 2005
Corporate Coder:
The conclusion seems to be: hey, get a bunch of really smart coders that know what they are doing, and suddenly you will reach nirvana. This is too simplistic. I have found that in big corporations the biggest problem is too many meetings that mean nothing - where key decisions like direction, architecture are never solved in a timely manner. Usually this is because the decision makers are so abstracted out of the process, so the software teams then flounder or lack real focus. The second to the last paragraph seems really silly too. How many companies can afford to play the Trial and Error game? There are similarities to building enterprise software systems and enterprise skyscrapers. There are a number of variously skilled people that can all concretely contribute to the building process.
comment at 31. December 2005
Saša Ebach:
Just a quick comment to phrase “How many companies can afford to play the Trial and Error game?”. Hiring decisions are ultimately all Trial and Error. No matter what field you are talking about. Be it a sales person or a high tech employee. Focusing on hiring the right people is the most important part of expanding any business. (see Good to Great: Why Some Companies Make the Leap . . . and Others Don’t)
comment at 31. December 2005
Dennis:
The way you make sure you’re hiring only great coders is to do like Joel said and get people who know Scheme, Haskell, and C pointers. Most programmers aren’t up to it. The ones who are will do just fine with anything else you throw at them.
comment at 31. December 2005
Alex Bunardzic:
Brian Fioca wrote:
The thing that’s wrong is this: “On average, average corporations will employ average people” (forgot the exact source of that quote).
The problem is in the word ‘average’. With average resources and average attitudes, you can’t help but expand only average efforts and produce and deliver average results.
Which means you must gain the competitive edge using some extra-curricular activities and gimmicks (e.g. political lobbying, barely legal under-the-table deals, spreading FUD, etc.)
I don’t know about you, but I’m not fond of being a part of unethical dealings. I’d rather strive to be out in the clear.
The real problem with the corporate setup is that it does not encourage putting above-average efforts in. For the simple reason that no one can reliably measure individual contribution to the success/failure of the corporate offering. You could outperform (or underperform) your colleagues by a factor of 10, no one would ever notice in a typical corporation. As the saying goes, “90% of success in the corporate world is simply showing up at your desk”.
comment at 31. December 2005
Alex Bunardzic:
Dennis wrote:
I vehemently disagree with that. First, if you haven’t already, you should watch Joel’s “12 Weeks with Geeks” DVD (I wrote about it here).
Frankly, I personally wouldn’t let all those geeks (who can do toughest recursion/pointers in their sleep) take my garbage out. I’m not sure where would my garbage end up if these guys were given the responsibility to handle it. They all looked like total retards in the Joels’ DVD.
I got seriously concerned about their mental acuity watching them scribbling on the whiteboard, trying to ‘calculate’ whether they could make it to the other end of the chasm that’s gaping between their window and the nearest ledge. Just watch carefully what they’re doing in that sequence, and it’ll become clear to you that these people who live and breathe pointers and recursions are utterly incapable of handling any real life challenge.
Would I hire such geeks to solve real life software problems in my company? Not in my wildest dreams.
comment at 31. December 2005
Kragen Sitaker:
Brian Fioca asks:
(As an aside, the real world contains many more kinds of places than that statement suggests.)
Aristotle has identified some delusions in the WASP article, delusions that seem common among “corporate management”. Knowing the delusions of your audience helps communication, but knowing them isn’t the same as believing them.
In the quote, Fioca asks what is “intrinsically wrong” with these delusions. He points out that it’s not that they are not unpopular. I believe it’s that they are wrong; they are mistaken beliefs. Guiding your actions by them is dangerous.
Some delusions are more dangerous than others. The delusion that touching insulated electrical cords is fatal would only inconvenience you slightly, most likely; the delusion that you can fly if you jump from a tall building may kill you.
The delusions we’re talking about fall in between: that Java makes your code comprehensible, that it contains “advanced features” missing in Perl that keep your code stable and maintainable, and so forth. They’ll cut you off from discourse with the most competent programmers, and they’ll substantially increase the technical risks and costs of your project, but your project might succeed anyway.
Usually when people complain about “the corporate management worldview”, they’re talking about managerialism, and that seems to be somewhat the case here. The problems with managerialism in general are outside the scope of this blog comment. Dijkstra has written extensively on the problems of applying it to intellectual work.
Aristotle writes:
I think that’s overstating the case.
If, by “maintainability”, you mean “ease of debugging and modification”, there’s a lot of empirical evidence that twice as much code means something like twice the effort to make a change or find a bug. (A little more, actually.) These different languages require different amounts of code to do the same tasks, due to the different libraries and abstraction facilities they have. So, at least in that way, some languages (such as Java) are much “less maintainable” than other languages (such as Smalltalk or Ruby).
Also, some other language attributes affect programmers’ ability to understand existing code; this matters because most of the time spent on “maintenance” is spent on understanding existing code. For example, many people report that Lisp’s punctuation, which makes everything look kind of the same, impedes readability for them; I find that the imperative style required by Java and Smalltalk (or rather their libraries) often obscures the intent of the code; Perl’s “DWIM” attitude and unexpected interactions between components often makes it hard for me to track down bugs in my Perl programs; and I have a harder time figuring out why my Haskell programs are using unexpected amounts of memory or time than I have with other languages.
If we include a broader spectrum of languages, this point becomes even clearer. Traditional BASIC has no explicit parameter-passing mechanism or variable locality; traditional C has the headaches of manual memory-management; assembly requires that you keep track of which registers you’re using for what. These factors do intrinsically affect maintainability.
The importance of good tools is common to many crafts. A master craftsperson can usually make do with poor tools, but is much more productive with good ones, whether they are writing code, building circuits, carving wood, dressing stones, or baking quiche. Sometimes the differences are quite large.
Languages themselves are not the only tools that matter here. I find Java much more maintainable when I am armed with IDEA, for example; compilers, debuggers, profilers, libraries, IDEs, and source-control tools all make substantial differences in my productivity.
However, I agree that the language and tool choice affects maintainability less than programmer expertise.
comment at 01. January 2006
Aristotle Pagaltzis:
Brian:
Ah. That does put your article in quite a different light. I wish you had phrased it along the lines of this comment, though, that is, framed the Java = maintainable assertions as convictions rather than fact (even if only subversively ;-)). I don’t think I’d have taken issue at all in that case.
Brian, again:
Careful: I don’t equate artists with great programmers. Great programmers are craftsmen and pragmatists. They may express themselves through their work, but they don’t do it to express themselves.
That said, it is true that they are hard to identify. The moral is probably that programmers need to be involved in the hiring process if you want to hire good programmers. I am reminded once more of things Paul Graham has said.
As for paradigm shifts, be sure not to miss Ben Tilly on Kuhn on Paradigm Shifts.
Tony:
I’d rather have two great programmers than one great teach lead and 4 juniors. But that example doesn’t really highlight the point, because in small teams, the randomness factor is, as you say, large.
OTOH, a team of 30, consisting almost exclusively of mediocre programmers, is worth less than a team of only 5 developers who can hit the high notes. I’d rather spend the resources required up front to find a small number of excellent developers than burn a lot more resources, over the course of the project, on a huge team of monkeys.
Frameworks help; but they do only to the extent that they match the application’s requirements. The more specialised your needs, the more architecture you will be building outside the structure afforded by the framework.
I disagree that this is a good analogy. Franchises are not frameworks in the software sense. Franchises instruct you on how to execute basic tasks of business. A franchise business is a processor that runs a franchise business executable. A franchise plan is equivalent to an application in the software sense, not a framework.
In software, things written repeatedly by programmers will sooner or later be abstracted away. Following a fixed, repeatable plan for building software really means that you haven’t abstracted away enough yet. A competitor who does will eat your lunch.
Hence RoR: a software framework extracted from an application in order for the team behind it not to have to repeat the same work in the next application. Your claim that what I wrote amounts to “we don’t need Rails, we’ll just hire smart programmers” misses the mark completely and misstates the purpose of software frameworks. Those smart programmers will build a Rails of their own if they find themselves doing repeated work and a Rails does not yet exist. (And will choose to build upon Rails by themselves if they find themselves doing a lot of work which the use of Rails would preempt.)
Kragen has an excellent article on this issue in the pipeline. I hope he manages to finish and publish it, one day. :-)
Of course, the analogy to a franchise looks believable on the surface and appeals greatly to business types; no wonder middle management generally operates on the delusions it does.
Kragen:
So it is.
The problem I faced is that I saw no easy way to incorporate those nuances within the frame of the argument I was trying to present. They are why the published revision of the article does not simply state, as earlier versions did, that:
but goes on to qualify:
I agree that even this insufficiently captures the points in question.
I had been wanting to discuss this in greater detail with you prior to publishing, but I didn’t know how to get hold of you and the article had already languished for such a long time that I decided to forge ahead anyway.
I hope that aspect doesn’t detract greatly from the overall argument.
comment at 01. January 2006
Kevin Smith:
What’s wrong with the [traditional/mainstream] corporate management world view?
It’s not compatible with my ideas of fun, productivity, and (in many cases) broad spiritual/ethical beliefs. I’ve worked at about twenty companies (salary and contract) over about 25 years. From banks and IBM to 3-person startups. I know what environments work best for me.
If you want to be a corporate coder, I have no problem with that. But the more shops that switch to an agile process, the more job opportunities that I would actually consider. Hence, my low-level advocacy for all things agile.
comment at 02. January 2006
Marginalia » Blog Archive » Easy Programming Languages:
[…] Update: I came across a related essay by Aristotle Pagaltzis called Maintainable Programmers. […]
pingback at 02. January 2006
Jayson Vantuyl:
I think there’s an even different disconnect here than mentioned above:
Those who can do a thing, do it. Those who can’t, manage.
At the core of the arguements is either “Your people should know what they’re doing. Hire good programmers and get good results.” versus “We want to engineer a process that takes the endless supply of cheaper codemonkeys and generates something usable.”.
Ironically, both of these are correct answers to different questions from different people.
Good programmers rarely can suffer working for someone who can’t do what they are capable of doing. Enumerate the possibilities.
Management can’t understand what you do and doesn’t give you the support needed to exceed (Management into Oblivion). This is not sustainable because generally gifted programmers quit.
Management can’t understand what you do but gives you the room and support to succeed (Effective Middlemen). This isn’t sustainable because eventually the programmer recognize the uselessness of their management and starts a startup.
Management can understand what you do and manages effectively. Of course, in this situation, good programmers usually ARE the management (usually this is a startup).
Essentially, gifted programmers don’t work for corporate management types for long.
Conversely, these people (henceforthe referred to as “MBAs”, used pejoratively) are left to do what they can. Since your average codemonkey will waste his time humping a stupid project for a visionless manager, these same management-types ALWAYS get the best out of codemonkeys. It’s a self fulfilling prophecy. If you manage capable people so badly that they leave, you’ll naively believe that capable people are “unreliable” and that the less capable are suitable because they are replacable and that your “process” will make everything work anyways.
This article essentially says that the corporate management (MBA) mindset is not even close to the right way to solve the problem. It is correct.
The referenced article says that, within the context of being a corporate manager who is incapable of writing good code yourself (and thus managing people who can), this process takes low quality programmers and forces them to behave a little better. In this way, that article is correct as well.
The problem is not that these people don’t understand what solves a problem. Programmers write code because they want to solve problems. MBAs us to work in such a way as to enabling the mediocre to repeatedly succeed cheaply enough that the savings amortized over the lifetime of the enterprise offsets the loss expended to later achieve optimal solutions (the above Franchise Scenario). Business types have no problem with a net loss if the short term win keeps them in business.
I love how some respondents use the word “artist” as a pejorative. It’s kind of like the way certain people use the word “Republican”, “Democrat”, “Feminist”, “Management”, etc. Essentially its a way to appear polite when covertly signalling other people which share your lack of respect for your opposition. A way of coopting the naming of a thing to communicate disdain for it.
In this case, the implication is that caring about “design” or “craftsmanship” is impractical, or at least that a process can somehow make a solution “good enough”. This is, of course, classic code monkey / management groupthink–and it benefits both of them to feel that way. Of course, they may be right. Hiring good programmers is useless if you’re out of business.
That said, the mistake is to then blindly trust management to sort it out because “it’s their job”, which is ironic because they are least suited (well, they do wear suits) to make the calls necessary to design their products. In the end, I don’t even bother to explain it anymore. People who need to ask the question are already too far gone to affect. How do you explain to someone that quality companies are built on quality people? If you don’t understand, it will be up to repeated failures at the hands of quality people to teach you.
I’m afraid that the only way to solve this problem will be for engineers and programmers to systematically remove MBAs from companies by repeatedly founding valuable startups and dominate business with value. Don’t sell out. Be brutal in keeping your environment pure. You’ll have to spend generations draining the money from the MBA types, since their primary skill is retaining it.
The proof is in the pudding. MBAs pull the double whammy. They get to trade in the analysis of what is “valuable”. They get to turn real world situations into “valuations”. It is no surprise that they dominate management decisions when they are the ones that assign relative value. It’s no wonder they hijack control of business.
The market is more discerning than this. Just crank out good software at a fraction of the cost and work to destroy the credibility of the MBA (believe me, most of Wall Street, Tyco, Worldcom, and Enron have already gone a long way).
Along the way, it may be necessary to reclaim the courts and the government, but that’s another discussion… :)
Seriously though, I can only hope that real, honest-to-goodness MBAs can read this and appreciate what I’m saying. People in management are competitive. This competition becomes manipulative. It is a matter of ethics and responsibility for MBAs to keep reality in their numbers and work as a group to prevent those of their number from “minimizing” in these ways.
They have a profound effect on the market. They determine which languages get press and nourishment. Agile languages are supremely important regardless of the supply of programmers for them. If IBM wants Python or Ruby programmers, there will be Python or Ruby programmers. Don’t underestimate your role in this.
Realize that employees (good programmers in particular) aren’t just a “resource”, but more appropriately an “asset”. Realize that you are fooling yourself if you can’t see where good programmers fit into your balance sheet.
When hiring a cheap programmer or two in place of a good one, realize that you’re replacing an asset with a much less valuable one. It may look like you’ve saved if you don’t properly value the assets you’re trading…
comment at 03. January 2006
Aristotle Pagaltzis:
Jayson: great stuff, thanks.
Kevin:
You will probably enjoy The Crooked Timber Of Software Development.
comment at 03. January 2006
How’s that for less code? [@lesscode.org]:
[…] about lesscode.org « Maintainable Programmers […]
pingback at 07. January 2006
Kevin Smith:
I just read that “crooked timber” article. Loved the parts about ethics and responsibility. Hated the parts about turning software development into Software Engineering. College is vastly overrated, and many professional licensing schemes are harmful to practitioners and clients alike. Not to mention that most current Software Engineering advocacy is anti-agile. Let’s not go down that road.
comment at 07. January 2006
Aristotle Pagaltzis:
I know. I find myself vigorously agreeing with half of each Hacknot article and vehemently disagreeing with the other half. I guess they are what one would call thought-provoking. :-)
What I mainly took away from that article is its primary subject: how the lack of any standards and ethics mean that software development is no profession; and that it is in our power, interest and responsibility to change that.
Which, as it happens, has a lot of overlap with lesscode.org’s mission.
comment at 07. January 2006
warpedvisions.org » Blog Archive » Maintainable programmers:
[…] February 6th, 2006 in Links Maintainable Programmers. Finding good programmers is really difficult. […]
pingback at 06. February 2006
Aristotle Pagaltzis:
Interesting relevant post by James Robertson.
comment at 13. May 2006