The Parable of the Two Programmers (1985)

There was a MOOC on Coursera called &quot;Irrational Behaviour&quot; and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to a point where he was fixing the door locks in 10 or 15 minutes with virtually no disturbances for the customers. His tips started to fade off and his customers became outraged at his 70$ charged for those 10 mins of work.<p>Conclusion: we don&#x27;t want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service.

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be <i>a lot</i> harder than expected<p>What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn&#x27;t have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy.<p>So he works long hours to fix the situation, then he burns out.<p>Source? This is somehow happened to me. Several times.<p>This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It&#x27;s easy for a beginner to believe he is that guy and then experience a death march [1] Things can go wrong for Alan, but he has a team to support him and his managers know he is working at something complicated.<p>I&#x27;d like to be Charles one day, but for now I&#x27;m Alan.<p>[1] <a href="https://en.wikipedia.org/wiki/Death_march_(project_management)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Death_march_(project_managemen...</a>

Related Hacker News comment: <a href="https://news.ycombinator.com/item?id=8941621" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8941621</a><p>From &#x27;Software Requirements &amp; Specifications&#x27; [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]:<p>&#x27;What do you think?&#x27; he asked. He was asking me to tell him my impressions of his operation and his staff. &#x27;Pretty good,&#x27; I said. &#x27;You&#x27;ve got some good people there.&#x27; Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.<p>&#x27;What did you think of Fred?&#x27; he asked. &#x27;We all think Fred is brilliant.&#x27; &#x27;He&#x27;s very clever,&#x27; I said. &#x27;He&#x27;s not very enthusiastic about methods, but he knows a lot about programming.&#x27; &#x27;Yes,&#x27; said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. &#x27;Fred did that. It&#x27;s the build-up of gross pay for our weekly payroll. No one else except Fred understands it.&#x27; His voice dropped to a reverent hush. &#x27;Fred tells me that he&#x27;s not sure he understands it himself.&#x27;<p>&#x27;Terrific,&#x27; I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. &#x27;But what about Jane?&#x27; I said. &#x27;I thought Jane was very good. She picked up the program design ideas very fast.&#x27;<p>&#x27;Yes,&#x27; said the DP Manager. &#x27;Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn&#x27;t really proved herself yet. We&#x27;ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren&#x27;t really difficult at all. Most of them turned out pretty simple. She hasn&#x27;t really proved herself yet -- if you see what I mean?&#x27;<p>I saw what he meant.<p>[0] <a href="http://www.amazon.co.uk/Requirements-Specifications-Software-Principles-Prejudices/dp/0201877120" rel="nofollow">http:&#x2F;&#x2F;www.amazon.co.uk&#x2F;Requirements-Specifications-Software...</a><p>[1] <a href="http://www.win.tue.nl/~wstomv/quotes/software-requirements-specifications.html" rel="nofollow">http:&#x2F;&#x2F;www.win.tue.nl&#x2F;~wstomv&#x2F;quotes&#x2F;software-requirements-s...</a>

I&#x27;ve lived this experience, many times over, and the story is true at it&#x27;s core.<p>Some folks might dismiss this as a fantasy scenario, and sure, it&#x27;s missing a lot of details. In the real world, the lone programmer doesn&#x27;t get to write an efficient program for different reasons: the software design is locked down by managers, there is fear of abandoning the poorly written legacy code, newer programming tools aren&#x27;t allowed because most developers don&#x27;t know them, or there is a sunk cost of an expensive software license that has already been purchased.<p>The story is symbolic, but the lessons are universally true, even today. For managers: conventional methods of judging productivity are unreliable. For developers: few organizations will enable you to work optimally.

I don&#x27;t believe some parts in the story.<p>1) In my experience people fresh out of college don&#x27;t deliver well tested code that goes beyond the spec. I&#x27;d rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data.<p>2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experienced coder. Specs are usually ambiguous and often don&#x27;t even describe the problem that actually needs to be solved. It takes a lot of talking to clients to discover what you actually need to do. Halfway through the project you&#x27;ll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you&#x27;ll end up with code that solves the wrong problem.<p>But then there are things I can absolutely relate to. Good solutions seem simple and obvious in retrospect. But it takes a lot of effort to come up with simple solutions.

<p><pre><code> Day What I Did TotLOC --- ----------------------- ------ Mon Prototype Possibilities 300 Tue Write Building Blocks 900 Wed Construct Major Content 1,700 Thu Add Features 2,200 Fri Refactor, Test, Deploy 300 Customer: Looks great. Thank you! Boss: Only 300 lines of code in 5 days? Boss: How can you be more efficient? Me: I could take Fridays off.</code></pre>

I dislike this strongly. It is attempting to demean a group of people without really giving them a fair chance. It exaggerates and vilifies the &quot;enterprise programmer&quot; while lionizing the young-but-inexperienced smart programmer. It&#x27;s a very common theme here on HN. It&#x27;s playing into the narrative of the young entrepreneur that can drop out of college and build the next successful start-up. The fact is that most people in that situation will fail the first few times as they gain experience. People who can operate like Alan, though obviously Alan does not deliver results, are very valuable in a company. Systems have a tendency to get more complex and you will need people who have experience dealing with that complexity, managing it, and reducing it.<p>Let me address the parable a bit more directly.<p>The parable is very hard for me to relate to because to me it seems like the two characters are cherry picked such that they&#x27;re vastly different in terms of skills. It looks to me like Charles is either much better than Alan at design or got lucky. I think the only wisdom that can be gleaned from the story is to not over-complicate your design. Charles and Alan both spend time upfront designing their code, but it seems that Charles came up with the better design and saw the simple kernel of the problem. That&#x27;s the only real difference between the two. Alan saw a problem that needed a lot of work and specs to get right, but Charles saw it was actually a very simple problem.<p>I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn&#x27;t figure it out, so it must have been a hard problem to know how to work with in the first place. Maybe Alan was working defensively to make sure he had all his bases covered in case the design turned out to be different than he initially anticipated. I can&#x27;t say.

A lot of people seem to think this is a story about programming. It&#x27;s not. It&#x27;s about perceptions. A good programmer knows that a certain portion of his work is managing perceptions. This is part of a skill-set known as &#x27;soft skills&#x27; and will get you farther than a perfect understanding of monads.

The issue that seems to be overlooked here is the objective value of solving the problem itself. Instead it focuses on the developers and their rewards.<p>A does a thing, it takes a long time, solves the problem and he becomes System Analyst.<p>C does a thing, it&#x27;s shorter in both time and effort, and he leaves the company a year later.<p>What about the value produced by the solution?<p>It&#x27;s clear that if a single (inexperienced and poorly communicative) developer can produce a satisfactory solution in a fraction of the time of a majorly architected approach then the first view (A) is overvalued.<p>The moral of the story seems to be something about how huffing and puffing, self-importance is rewarded over a thought out appropriate solution to the task at hand.<p>How about going forward in the story? A sequel-sequel?<p>At Automated, their unrealistic approach to planning and development, and their focus on titles and rewards led to bloated and unmaintainable software, where everyone in the company fought to make something &quot;smart&quot; that demonstrated their intelligence and worthiness of being rewarded - the problem specifications being nothing more than a means to achieving this.<p>At C, Charles either gained the experience necessary to understand the reasons for communicating efforts and planning to the rest of his management and went on to design appropriate solutions in another company, or he decided that being rewarded for his efforts was more important than solving problems and gaining domain experience and joined the above.

I know it&#x27;s a parable and the objective is to send the message that &quot;customers value complexity&quot;. In the enterprise we see lots of news where a business spend millions in a certain solution and we sometimes think it was overspend.<p>But I see another point why the story reflects the reality in some aspects: experienced developers tends to overengineer a problem, and I recall the &#x27;hello word&#x27; joke about programmer evolution. But at the same time, the novice, rarelly will deliver a good sollution in the first time.<p>In my point of view, the simpler solution, will just work, could have lots of technical debts and could be hard to scale, while the complex one, could turn costly to support. Its very hard to find an optimal point between both.

This brings to mind the maxim, &quot;A job, no matter how small, will grow to fit the time and resources available&quot;.

If there is a second sequel to this story, it&#x27;s that the one guy goes on to start a successful company, and the other guy is entrenched in the politics of his company.<p>I think this would be a better comparison if space invaders was left out. Or perhaps if it were, &quot;he scribbled for a while, then played space invaders, then scribbled some more.&quot;, as opposed to him starting with nothing but space invaders. The other guy began by inventing problems rather than solving them.<p>It comes down to, a direct, though outwardly puzzling, solution that is apt VS. an indirect, political, frustrating(for everyone), bloated, slow solution.<p>If it weren&#x27;t a programming department, and it were two different companies, survival of the fittest would kick in, and the better faster guy would be more successful. And, it has. We now learn from the successful companies that are similar to the space invader guy and it doesn&#x27;t seem so weird. The fact that people were catching on to this idea in 1985 is pretty striking.<p>This is anecdotal and doesn&#x27;t really teach the bigger picture. It&#x27;s also not encouraging, as it doesn&#x27;t lead the user to the correct path of action.<p>It really needs a second sequel where the space invader guy goes on to be wildly successful to be a good story.

That is why I love perl: the manager can not understand it and can not say it was simple.

I can see exactly where Charles went wrong. Here is how the story should have gone:<p>Charles implements an entire interpreted language with garbage collection and an incomprehensibly coded virtual machine. Everything is documented and works flawlessly at that level, however. Nary a bug can be found by anyone experimenting with the language.<p>Charles writes the program in 30 lines of this language, which appear fairy simple on the surface, but rely on some deep semantics (that Alan&#x27;s team doesn&#x27;t even comprehend, for instance, let alone management, without studying).<p>In this case, nobody can dismiss the problem as being something easy that a junior programmer can solve, and Alan&#x27;s team look like troglodytes from the Dark Ages. All the more so because their buggy, incomplete program is over 2500 lines, while Charles&#x27; language fits into 2300.<p>:)

Rarely (unless you are working on your hobby project) you get a chance to make program simple. There are inherently complex requirements that can&#x27;t be changed for political reasons, complex legacy interfaces to conform to et c.<p>Interestingly, most programmers seem to think that inherent complexity doesn&#x27;t exist, i.e. that any requirements can be translated into a simple program. The result of this approach are leaky abstractions that later on cause much pain to the developer and anyone maintaining the codebase.

Quite an interesting article. The best part is that the article does not judge. It simply lays down facts for us and leaves the opinionated part onto us.

I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.<p>On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).<p>Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.

This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better program in fewer LOC) and if you don&#x27;t then it can get much more complex. It&#x27;s like the difference between trying to make a machine fly by making wings out of feathers and having it flap, or understanding the principles of aerodynamics and making a fixed wing out of canvas.<p>However, for most non-trivial problems understanding everything up front isn&#x27;t possible. To know what works you may need to create prototypes and iterate, abandoning things which don&#x27;t work or which end in a hairball of complexity and getting opinions from testers. In that situation just intuiting a solution and then typing in the code won&#x27;t work and the more formalised process might work better.

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

I think it&#x27;s actually a great little story because in the end, everyone got what they wanted.<p>The lone programmer did his work, got paid for it and left, hopefully to find a company with a better fit.<p>The team was hired and got paid to do their work and, while doing so, created a process that the company felt comfortable with. Perhaps they are still working there today.<p>Everyone seems to have taken what they needed and got what they wanted.<p>There are an infinite number of ways to slice a thing. Choose one and figure out if it works for you. This applies to both sides, the worker and the management.

The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political &#x2F; economic reasons we sometimes have to pretend its a vocation or profession, but it really isn&#x27;t in actual application. Software architecture should be in the &quot;fine arts&quot; department at university, not a branch of finance, engineering, or math.<p>In art, people expect the highest quality producers to instantly produce effortless appearing product (music, dance, painting, sport, drama, whatever) and are generally willing to pay for quality unless they&#x27;re a hopelessly tasteless neanderthal. The only time effort is rewarded in art is when parents watch their (own) kids perform.<p>One epic fail of the parable is it was written in an era of C (pascal?) dominance where 500 LOC means something different then from now. That would be at least 2000 lines of boilerplate-ish java (think of the classic &quot;enterprise hello world&quot; java implementation) or 10 lines of clojure and pretty much everything else fits in between. Something that has stayed constant over the decades, from my observation, is a &quot;complicated functional block&quot; takes maybe three hours long term total average, a &quot;little bit less than before&#x2F;after lunchhour&quot;, and the only determiner of how many LoC are produced in that time is language quality and programmer quality. Maybe another way to phrase it, is a correctly sized block on a project flowchart takes a couple hours in all languages for a given class of programmer ability.

How neat to see this little article pop up from 1985. Professor Neil Rickert was one of my computer science profs while I was at Northern Illinois University. He was a pretty solid teacher and beyond a doubt, knows his shit in and out. Definitely a highly respected professor within the computer science ranks. He&#x27;s now retired or Professor Emeritus now, I believe.

And if the specs change after the code was written (as usually happens in real life), who&#x27;s code would have been easier to update? There is a reason experienced people may put more effort in to certain areas they junior programmers, they will have an idea what is likely to change and when.

Oh god, this thing&#x27;s actually getting traction here.<p>Look, there&#x27;s no moral to this story and very little to glean from it because it&#x27;s about a situation that&#x27;s ridiculous on its face. It&#x27;s written to appeal to cowboy programmers to make them feel better about their prejudices in software development.<p>Can <i>any</i> of you actually relate a real-world case where a 4-month-long team-driven effort produced some code to solve a problem that could be solved by one cowboy in 3 months and 20% as many lines?

Thanks. I have read this many years back, but could not find it anymore.

I can&#x27;t wait to get out of software development.<p>I&#x27;m just a couple of years removed from uni and I&#x27;m already planning my exit. My first corporate job was a huge eye-opener. This type of stuff left and right with zero career advancement and complete disdain from corporate.<p>I&#x27;m not even thirty and I plan on retiring and starting my own business (tech or other) by the time I&#x27;m 40. The only good thing about tech is that I can actually find a job and that the pay is above average giving me the opportunity to take the money and run!<p>It&#x27;s a complete shame too because I enjoy solving problems through code. I love learning about new technologies. But everywhere I look software developers are completely screwed, absolute wasteland of an industry.

If we pretend this was a real story, Charles&#x27;s manager should really have spoken to Charles about playing Space Invaders for 2 weeks straight. While Charles may be getting some valuable thinking time in, I can imagine he&#x27;s also pissing off his colleagues who will feel they&#x27;re working to support a guy messing around.<p>The exact nature of that depends on Charles, his manager, and the company, but it is possible to have those conversations without diving in and accusing Charles of goofing off.<p>Also, the manager made a huge mistake in judging the code based on what he saw. He should have spoke to Charles about this and tried to glean some insight into how it came to look so easy. If I&#x27;m speculating, the manager was looking to punish Charles for his behaviour and went about it completely the wrong way.

This parable is somewhat untrue, as it pats over the &quot;good students engineers&quot; shoulders, while throwing &quot;cowboy programmers&quot; out in the cold.<p>Unless you are producing libraries or frameworks, management don&#x27;t care about internals of software. It&#x27;s an engineers&#x27; problem next time they ask for a modification. Management care about having their problems solved. That&#x27;s why relations between management and engineers are so notoriously dysfunctional: engineers want to produce art, while management wants to sell stuff to customers.<p>A manager inspecting a code? Really? A manager congratulating with engineers for releasing a half-working software while going off budget? Seriously? Managers hate engineers as much an normal people hate lawyers: they make everything sound way too complicated to squeeze more comfort zone to roam into.<p>Lone cowboy programmers that can conjure working stuff in a minimum time are praised by management, and insulted by colleagues.<p>And, since this parable was probably written by a disgruntled, good scholar engineer, I think this whole story is a little biased...