9 ms·

The Parable of the Two Programmers (1985)

381 points by ims 12y ago

sidcool 12y ago
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.
- smasuch 12y ago
  I thought this was a fictional story.
  - thaumaturgy 12y ago
    It might be the most fictional story ever written about programming. It's completely ridiculous.
    - javert 12y ago
      I don't think it's ridiculous at all. Have you ever worked in the defense industry?
      - thaumaturgy 12y ago
        Yes, actually, I have. So this story isn't ridiculous because it applies to a niche that it never mentions?
  - sidcool 12y ago
    It might be, my intention was to highlight the fact that the article is laid down as a set of facts with no judgement. It's not like Charles was a hero. It just shows how Alan was rewarded. It's like reading something as simple as fate.
- Retra 12y ago
  Is this sarcasm? The article pretty clearly judges in an extremely opinionated way. It's a shame it never actually stated the specification of the program. It seems like that would be the kind of thing you would need to know to form a fair opinion.
  - sidcool 12y ago
    It's not sarcasm. I really interpreted the article this way. Might not be the correct interpretation.
    - javert 12y ago
      You got it right. Perhaps a better way to put it would be to say that the article teaches by demonstration instead of teaching by assertion.
      - smasuch 12y ago
        But, it's a fictional story. I can make up a fictional story to demonstrate anything, regardless if it's true in the real world.
jebediah 12y ago
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.
- javert 12y ago
  Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs, re-writing things, doing administrative work, and so on towards the time elapsed. And even then it would vary so much from one project to the next that you couldn't get a reasonable representative number, though 5 LOC per day would certainly be possible.
  - jebediah 12y ago
    I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb
    - javert 12y ago
      Don't ever let yourself think you are dumb. It's a lot more harmful to your psychology and to learning than it may at frist appear. If you can't figure something out, you are just lacking some knowledge you need. I wish I had learned that a long time ago. Being dumb is never the explanation for not understanding or figuring out something.
- f2f 12y ago
  don't be discouraged, it's par for the course. we're talking about quality lines of code: debugged, qa'd, and working as expected. perhaps even after the customer has had a chance to peruse the beta. you will be surprised how much time you'll spend in meetings and how hard navigating and contributing to large projects becomes. curiously, the number of lines of quality code expected by a developer has not changed much since "the mythical man month" was written, which was about IBM machines in the 60s, despite the obvious advances in programming languages and programming environments. it's still around 10 or so.
beloch 12y ago
This brings to mind the maxim, "A job, no matter how small, will grow to fit the time and resources available".
- sidcool 12y ago
  Well stated. I will jot it down for my next meeting with my manager :)
  - javert 12y ago
    Shhh. It's a secret. Use it to your advantage, don't tell your manager! In all seriousness though, your manager probably won't take kindly to hearing your advice about project management.
- gkoberger 12y ago
  http://en.wikipedia.org/wiki/Parkinson%27s_law http://en.wikipedia.org/wiki/Parkinson%27s_law
deleted 12y ago
[deleted]
- kylec 12y ago
  I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed. Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem.
  - deleted 12y ago
    [deleted]
  - greenyoda 12y ago
    "I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed." That's also how I interpreted it (based on personal experience). "Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem." Or he may have been playing games while taking a break from thinking.
  - gknoy 12y ago
    It's not that the problem was simple -- the other team's example shows that it was not. Rather, programmer C took the time to think about the problem enough, and write code that was elegant enough, that it __looked__ simple. Simple solutions almost always look easy in hindsight, but often are not simple to arrive at.
    - greenyoda 12y ago
      "It's not that the problem was simple -- the other team's example shows that it was not" Not necessarily. It might show that the other team was either (1) not smart enough to realize the problem's simplicity, or (2) deliberately playing the political game of making the problem appear hard because they knew that in the end they'd get more recognition. The lead programmer, Alan, got to have three people working for him, which could have been a step up for him on the corporate ladder. The corporate world is full of this kind of empire-building.
- 12y ago
thaumaturgy 12y ago
Oh god, this thing's actually getting traction here. Look, there's no moral to this story and very little to glean from it because it's about a situation that's ridiculous on its face. It's written to appeal to cowboy programmers to make them feel better about their prejudices in software development. Can any 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?
- arethuza 12y ago
  Absolutely, I finished (as in actually got the system to meet requirements) a system in 6 weeks that a team of ~15 (all gone by the time I had got there) had failed to do in a year. Their system had many thousands of classes, mine probably had less than 50. Theirs used pretty much every technology in J2EE (this was a few years back) - mine used a very small set. I didn't even have to work very hard....
- deleted 12y ago
  [deleted]
- Hermel 12y ago
  Yes, I've seen situations like this. As a rule of thumb, problems that fit into the head of one person are more efficiently solved by one person on its own than by a team.
  - vkjv 12y ago
    This, 1000 times, this. If you ever find yourself having difficulty cleanly separating a task, than you are going to spend more time defining the separation and integrating the parts than have having a single person do the task.
- lawl 12y ago
  Yes. If you want to complain about the exact numbers, start with these > Charles announces he has completed the project. He submits a 500 line program. > Charles did produce about 5 lines of code per day. This is perhaps a little above average. Obviously that's not the point though.
wting 12y ago
Related Hacker News comment: https://news.ycombinator.com/item?id=8941621 https://news.ycombinator.com/item?id=8941621 From 'Software Requirements & Specifications' [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]: 'What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. 'Pretty good,' I said. 'You've got some good people there.' 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. 'What did you think of Fred?' he asked. 'We all think Fred is brilliant.' 'He's very clever,' I said. 'He's not very enthusiastic about methods, but he knows a lot about programming.' 'Yes,' 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. 'Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. 'Fred tells me that he's not sure he understands it himself.' 'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She picked up the program design ideas very fast.' 'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet -- if you see what I mean?' I saw what he meant. [0] http://www.amazon.co.uk/Requirements-Specifications-Software-Principles-Prejudices/dp/0201877120 http://www.amazon.co.uk/Requirements-Specifications-Software... [1] http://www.win.tue.nl/~wstomv/quotes/software-requirements-specifications.html http://www.win.tue.nl/~wstomv/quotes/software-requirements-s...
akamaka 12y ago
I've lived this experience, many times over, and the story is true at it's core. Some folks might dismiss this as a fantasy scenario, and sure, it's missing a lot of details. In the real world, the lone programmer doesn'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't allowed because most developers don't know them, or there is a sunk cost of an expensive software license that has already been purchased. 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.
anaolykarpov 12y ago
There was a MOOC on Coursera called "Irrational Behaviour" 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. Conclusion: we don'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.
- rachelbythebay 12y ago
  I hit this on HN a couple of years ago: http://www.90percentofeverything.com/2010/12/16/adding-delays-to-increase-perceived-value-does-it-work/ http://www.90percentofeverything.com/2010/12/16/adding-delay... I also wrote about it. It's real. Many customers are not happy if you make it seem too easy.
- Iv 12y ago
  > Conclusion: we don'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. But is that irrational? This seems to be a personal preference. By refusing to pay the same price for 10 minutes of work or one hour of work, we assert that we do believe in a certain income equality. "Disturbing someone for one hour vs 10 minutes" is not a necessarily irrational way to look at the situation.
  - javert 12y ago
    No, people get angry at being charged $70 for 10 minutes of work because they think they're getting cheated, even though in this case they aren't. You're not going to find your rationalization for socialism here.
    - jacalata 12y ago
webreac 12y ago
That is why I love perl: the manager can not understand it and can not say it was simple.
- jarcane 12y ago
  I wonder how much language popularity is affected by this effect. We Lisp/FP fans crow about how easy and quick dev in more expressive languages is, but to a clueless manager that's potentially exactly the problem. If it doesn't look like work, then the manager is apt to wonder what they're paying you for. Whereas JavaEE ...
  - gwern 12y ago
    APL should've been much more popular if prestige by intimidation was a major factor.
jakobegger 12y ago
I don't believe some parts in the story. 1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data. 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'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'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem. 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.
- deleted 12y ago
  [deleted]
- rando289 12y ago
  > I don't believe some parts in the story. Cool story, but I have trouble believing parts of it.
- jacquesm 12y ago
  If it even remotely conforms to the spec I'd say that's gold. More often than not 'barely' translates into 'does not bear any resemblance to'.
- stestagg 12y ago
  Re 2) I've done this a few times. The trick is to ignore the detail of the spec, and understand what they actually want better than they do. If you get that right, then the actual coding becomes insignificant, and everyone is happy
- colomon 12y ago
  It's explicitly labeled a parable: "a simple story used to illustrate a lesson." It's not meant to be literally true. The second programmer's inexperience is just another reason why his boss judges his work to obviously have been easy.
ai_ja_nai 12y ago
This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold. Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are so notoriously dysfunctional: engineers want to produce art, while management wants to sell stuff to customers. 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. Lone cowboy programmers that can conjure working stuff in a minimum time are praised by management, and insulted by colleagues. And, since this parable was probably written by a disgruntled, good scholar engineer, I think this whole story is a little biased...
- cshimmin 12y ago
  I think you missed the point.
  - vegabook 12y ago
    ...though the idea that "engineers want to produce art, while management wants to sell stuff" has a lot of truth, and does have oblique relevance to the post, in the sense that Charles' "goofing off" was about thinking about the best way to abstract the problem and write it elegantly and concisely.
  - ai_ja_nai 12y ago
    tell me, please
scott_w 12y ago
If we pretend this was a real story, Charles'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's also pissing off his colleagues who will feel they're working to support a guy messing around. 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. 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'm speculating, the manager was looking to punish Charles for his behaviour and went about it completely the wrong way.
- ricefield 12y ago
  And that is why this is a parable—not a real story, and not intended to be read as one.
motters 12y ago
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't then it can get much more complex. It'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. However, for most non-trivial problems understanding everything up front isn't possible. To know what works you may need to create prototypes and iterate, abandoning things which don'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't work and the more formalised process might work better.
- TheOtherHobbes 12y ago
  The parable is really about the nature of corporate politics and the art of perception management. I'm not sure how obvious the underlying point is -> programming languages and methodologies are structured by political requirements. Programmer A is writing software. He knows nothing about perception management and status plays. Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status. The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it. IMO the interesting question is how much this applies to coding culture and language and OS design as a whole.
- marcosdumay 12y ago
  > However, for most non-trivial problems understanding everything up front isn't possible. You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems. That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.
rkachowski 12y ago
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. A does a thing, it takes a long time, solves the problem and he becomes System Analyst. C does a thing, it's shorter in both time and effort, and he leaves the company a year later. What about the value produced by the solution? It'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. 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. How about going forward in the story? A sequel-sequel? 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 "smart" that demonstrated their intelligence and worthiness of being rewarded - the problem specifications being nothing more than a means to achieving this. 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.
hotBacteria 12y ago
The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected 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't have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy. So he works long hours to fix the situation, then he burns out. Source? This is somehow happened to me. Several times. This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It'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. I'd like to be Charles one day, but for now I'm Alan. [1] https://en.wikipedia.org/wiki/Death_march_(project_management) https://en.wikipedia.org/wiki/Death_march_(project_managemen...
- alephnil 12y ago
  If this story had happened in real life, and the problem had been more complicated than anticipated, and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed, so in that case the project would be likely to fail, or at least be severely delayed. However, Alan was making the problem more complicated by introducing a lot of accidental complexity, and I have often seen that this is done even when the problem is more complicated than anticipated. Such a project could easily create enough work for 10-15 people in the hypothetical scenario in the article if the project had enough necessary complexity to be a four person project. It is very hard to distinguish between what is necessary and accidental complexity, and that is precisely the point of the article. Prestige is very often bound to how many subordinates you have rather than how well you solve a particular task, so making your project artificially complex can be a strategy for climbing toward upper management. This may of cause be a conscious or unconscious from the employee/manager in question.
  - jackweirdy 12y ago
    > ... and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed Not to mention, the company will be paying Alan and his team much more than they’re paying Charles. It’s my suspicion that people will give more weight to people they’re paying more, simply because they’re perceived as more valuable - independent of any other hard data. So despite having already spent more money on Alan, they’d be likely to continue doing so, due to the perception of hard work and the perceived value to the company.
eludwig 12y ago
I think it's actually a great little story because in the end, everyone got what they wanted. The lone programmer did his work, got paid for it and left, hopefully to find a company with a better fit. 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. Everyone seems to have taken what they needed and got what they wanted. 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.
edw519 12y ago
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.
- raldi 12y ago
  I don't understand; your numbers add up to 5400, not 300.
  - lorenzk 12y ago
    Total lines of code kept increasing until he was able to refactor everything on Friday and cut them back down to 300.
  - EliRivers 12y ago
    The final column isn't LoC written that day; it's LoC in total. Friday was spent refactoring (what we in the old days called "rewriting", before the hipsters made it cool); taking the code that was already working, and making it smaller, lighter, better.
    - frostmatthew 12y ago
      > what we in the old days called "rewriting", before the hipsters made it cool Calling it refactoring dates back to at least the early 90s[1], which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler[2]. [1] http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf [2] http://www.amazon.com/gp/product/0201485672 http://www.amazon.com/gp/product/0201485672
anodari 12y ago
I know it's a parable and the objective is to send the message that "customers value complexity". In the enterprise we see lots of news where a business spend millions in a certain solution and we sometimes think it was overspend. 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 'hello word' joke about programmer evolution. But at the same time, the novice, rarelly will deliver a good sollution in the first time. 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.
VLM 12y ago
The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political / economic reasons we sometimes have to pretend its a vocation or profession, but it really isn't in actual application. Software architecture should be in the "fine arts" department at university, not a branch of finance, engineering, or math. 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're a hopelessly tasteless neanderthal. The only time effort is rewarded in art is when parents watch their (own) kids perform. 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 "enterprise hello world" 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 "complicated functional block" takes maybe three hours long term total average, a "little bit less than before/after lunchhour", 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.
- black_knight 12y ago
  While software architecture certainly is an art, I would not say it is unique in that aspect among the fields you mentioned. Both engineering and maths should be considered art in their own rights. If you consider abstract mathematics, it is easily seen that many mathematicians find most of their inspiration in the aesthetics of their ideas. Somehow the way we teach maths obscures this fact from the students. Oh, and if you didn't already: Read «Zen and The Art of Motorcycle Maintenance». Aside from being a great story, it goes into detail about how technical work becomes art when done with Quality in mind.
jorjordandan 12y ago
A lot of people seem to think this is a story about programming. It's not. It'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 'soft skills' and will get you farther than a perfect understanding of monads.
danschumann 12y ago
If there is a second sequel to this story, it's that the one guy goes on to start a successful company, and the other guy is entrenched in the politics of his company. I think this would be a better comparison if space invaders was left out. Or perhaps if it were, "he scribbled for a while, then played space invaders, then scribbled some more.", as opposed to him starting with nothing but space invaders. The other guy began by inventing problems rather than solving them. It comes down to, a direct, though outwardly puzzling, solution that is apt VS. an indirect, political, frustrating(for everyone), bloated, slow solution. If it weren'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't seem so weird. The fact that people were catching on to this idea in 1985 is pretty striking. This is anecdotal and doesn't really teach the bigger picture. It's also not encouraging, as it doesn't lead the user to the correct path of action. It really needs a second sequel where the space invader guy goes on to be wildly successful to be a good story.
Periodic 12y ago
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 "enterprise programmer" while lionizing the young-but-inexperienced smart programmer. It's a very common theme here on HN. It'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. Let me address the parable a bit more directly. 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'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'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. I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn'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't say.
- ploxiln 12y ago
  This is indeed a comment-baity article. It is fiction, those two people didn't really exist and do those things. It gets programmers/developers riled up - because it's so believable. It is indeed the case that the characters are vastly different in terms of skill, and that is sort of the point. Alan did spend time developing his skills, but it was focused on frameworks and processes, and not effective programming or problem solving. Maybe he just didn't have the right start, didn't know what he didn't know, and just went the wrong way from there. But management, and Alan himself, can't tell the difference. I think that's the ultimate take-away. Non-programmers and "bad" programmers can't recognize good programming, even if they look at results. Well they can, but it takes a lot of time and luck to come across comparable situations. It seems like an intractable problem. They don't know who to trust; and there doesn't seem to be a way to find out for them, except to be genuinely good at developing software... but how to know which way to go about that?
moca 12y ago
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. 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). 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.
deleted 12y ago
[deleted]
kazinator 12y ago
I can see exactly where Charles went wrong. Here is how the story should have gone: 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. 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's team doesn't even comprehend, for instance, let alone management, without studying). In this case, nobody can dismiss the problem as being something easy that a junior programmer can solve, and Alan's team look like troglodytes from the Dark Ages. All the more so because their buggy, incomplete program is over 2500 lines, while Charles' language fits into 2300. :)
PhoenixWright 12y ago
I can't wait to get out of software development. I'm just a couple of years removed from uni and I'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. I'm not even thirty and I plan on retiring and starting my own business (tech or other) by the time I'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! It'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.
- aidenn0 12y ago
  This comment is more for others than for you, but there are good companies out there that are engineering focused. Almost none of them are corporations in which "software" is just one division of many,
- tripzilch 12y ago
  > It's a complete shame too because I enjoy solving problems through code. Who/what's there to stop you doing just that, once you have taken "the opportunity to take the money and run"?
gpvos 12y ago
Thanks. I have read this many years back, but could not find it anymore.
collyw 12y ago
And if the specs change after the code was written (as usually happens in real life), who'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.
speby 12y ago
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's now retired or Professor Emeritus now, I believe.
rumcajz 12y ago
Rarely (unless you are working on your hobby project) you get a chance to make program simple. There are inherently complex requirements that can't be changed for political reasons, complex legacy interfaces to conform to et c. Interestingly, most programmers seem to think that inherent complexity doesn'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.

381 points by ims 12y ago

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.

smasuch 12y ago
I thought this was a fictional story.
- thaumaturgy 12y ago
  It might be the most fictional story ever written about programming. It's completely ridiculous.
  - javert 12y ago
    I don't think it's ridiculous at all. Have you ever worked in the defense industry?
    - thaumaturgy 12y ago
      Yes, actually, I have. So this story isn't ridiculous because it applies to a niche that it never mentions?
- sidcool 12y ago
  It might be, my intention was to highlight the fact that the article is laid down as a set of facts with no judgement. It's not like Charles was a hero. It just shows how Alan was rewarded. It's like reading something as simple as fate.
Retra 12y ago
Is this sarcasm? The article pretty clearly judges in an extremely opinionated way. It's a shame it never actually stated the specification of the program. It seems like that would be the kind of thing you would need to know to form a fair opinion.
- sidcool 12y ago
  It's not sarcasm. I really interpreted the article this way. Might not be the correct interpretation.
  - javert 12y ago
    You got it right. Perhaps a better way to put it would be to say that the article teaches by demonstration instead of teaching by assertion.
    - smasuch 12y ago
      But, it's a fictional story. I can make up a fictional story to demonstrate anything, regardless if it's true in the real world.

jebediah 12y ago

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.

javert 12y ago
Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs, re-writing things, doing administrative work, and so on towards the time elapsed. And even then it would vary so much from one project to the next that you couldn't get a reasonable representative number, though 5 LOC per day would certainly be possible.
- jebediah 12y ago
  I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb
  - javert 12y ago
    Don't ever let yourself think you are dumb. It's a lot more harmful to your psychology and to learning than it may at frist appear. If you can't figure something out, you are just lacking some knowledge you need. I wish I had learned that a long time ago. Being dumb is never the explanation for not understanding or figuring out something.
f2f 12y ago
don't be discouraged, it's par for the course. we're talking about quality lines of code: debugged, qa'd, and working as expected. perhaps even after the customer has had a chance to peruse the beta. you will be surprised how much time you'll spend in meetings and how hard navigating and contributing to large projects becomes. curiously, the number of lines of quality code expected by a developer has not changed much since "the mythical man month" was written, which was about IBM machines in the 60s, despite the obvious advances in programming languages and programming environments. it's still around 10 or so.

beloch 12y ago

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

sidcool 12y ago
Well stated. I will jot it down for my next meeting with my manager :)
- javert 12y ago
  Shhh. It's a secret. Use it to your advantage, don't tell your manager! In all seriousness though, your manager probably won't take kindly to hearing your advice about project management.
gkoberger 12y ago
http://en.wikipedia.org/wiki/Parkinson%27s_law http://en.wikipedia.org/wiki/Parkinson%27s_law

deleted 12y ago

[deleted]

kylec 12y ago
I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed. Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem.
- deleted 12y ago
  [deleted]
- greenyoda 12y ago
  "I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed." That's also how I interpreted it (based on personal experience). "Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem." Or he may have been playing games while taking a break from thinking.
- gknoy 12y ago
  It's not that the problem was simple -- the other team's example shows that it was not. Rather, programmer C took the time to think about the problem enough, and write code that was elegant enough, that it __looked__ simple. Simple solutions almost always look easy in hindsight, but often are not simple to arrive at.
  - greenyoda 12y ago
    "It's not that the problem was simple -- the other team's example shows that it was not" Not necessarily. It might show that the other team was either (1) not smart enough to realize the problem's simplicity, or (2) deliberately playing the political game of making the problem appear hard because they knew that in the end they'd get more recognition. The lead programmer, Alan, got to have three people working for him, which could have been a step up for him on the corporate ladder. The corporate world is full of this kind of empire-building.
12y ago

thaumaturgy 12y ago

Oh god, this thing's actually getting traction here. Look, there's no moral to this story and very little to glean from it because it's about a situation that's ridiculous on its face. It's written to appeal to cowboy programmers to make them feel better about their prejudices in software development. Can any 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?

arethuza 12y ago
Absolutely, I finished (as in actually got the system to meet requirements) a system in 6 weeks that a team of ~15 (all gone by the time I had got there) had failed to do in a year. Their system had many thousands of classes, mine probably had less than 50. Theirs used pretty much every technology in J2EE (this was a few years back) - mine used a very small set. I didn't even have to work very hard....
deleted 12y ago
[deleted]
Hermel 12y ago
Yes, I've seen situations like this. As a rule of thumb, problems that fit into the head of one person are more efficiently solved by one person on its own than by a team.
- vkjv 12y ago
  This, 1000 times, this. If you ever find yourself having difficulty cleanly separating a task, than you are going to spend more time defining the separation and integrating the parts than have having a single person do the task.
lawl 12y ago
Yes. If you want to complain about the exact numbers, start with these > Charles announces he has completed the project. He submits a 500 line program. > Charles did produce about 5 lines of code per day. This is perhaps a little above average. Obviously that's not the point though.

wting 12y ago

Related Hacker News comment: https://news.ycombinator.com/item?id=8941621 https://news.ycombinator.com/item?id=8941621 From 'Software Requirements & Specifications' [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]: 'What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. 'Pretty good,' I said. 'You've got some good people there.' 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. 'What did you think of Fred?' he asked. 'We all think Fred is brilliant.' 'He's very clever,' I said. 'He's not very enthusiastic about methods, but he knows a lot about programming.' 'Yes,' 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. 'Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. 'Fred tells me that he's not sure he understands it himself.' 'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She picked up the program design ideas very fast.' 'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet -- if you see what I mean?' I saw what he meant. [0] http://www.amazon.co.uk/Requirements-Specifications-Software-Principles-Prejudices/dp/0201877120 http://www.amazon.co.uk/Requirements-Specifications-Software... [1] http://www.win.tue.nl/~wstomv/quotes/software-requirements-specifications.html http://www.win.tue.nl/~wstomv/quotes/software-requirements-s...

akamaka 12y ago

I've lived this experience, many times over, and the story is true at it's core. Some folks might dismiss this as a fantasy scenario, and sure, it's missing a lot of details. In the real world, the lone programmer doesn'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't allowed because most developers don't know them, or there is a sunk cost of an expensive software license that has already been purchased. 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.

anaolykarpov 12y ago

There was a MOOC on Coursera called "Irrational Behaviour" 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. Conclusion: we don'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.

rachelbythebay 12y ago
I hit this on HN a couple of years ago: http://www.90percentofeverything.com/2010/12/16/adding-delays-to-increase-perceived-value-does-it-work/ http://www.90percentofeverything.com/2010/12/16/adding-delay... I also wrote about it. It's real. Many customers are not happy if you make it seem too easy.
Iv 12y ago
> Conclusion: we don'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. But is that irrational? This seems to be a personal preference. By refusing to pay the same price for 10 minutes of work or one hour of work, we assert that we do believe in a certain income equality. "Disturbing someone for one hour vs 10 minutes" is not a necessarily irrational way to look at the situation.
- javert 12y ago
  No, people get angry at being charged $70 for 10 minutes of work because they think they're getting cheated, even though in this case they aren't. You're not going to find your rationalization for socialism here.
  - jacalata 12y ago

webreac 12y ago

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

jarcane 12y ago
I wonder how much language popularity is affected by this effect. We Lisp/FP fans crow about how easy and quick dev in more expressive languages is, but to a clueless manager that's potentially exactly the problem. If it doesn't look like work, then the manager is apt to wonder what they're paying you for. Whereas JavaEE ...
- gwern 12y ago
  APL should've been much more popular if prestige by intimidation was a major factor.

jakobegger 12y ago

I don't believe some parts in the story. 1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data. 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'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'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem. 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.

deleted 12y ago
[deleted]
rando289 12y ago
> I don't believe some parts in the story. Cool story, but I have trouble believing parts of it.
jacquesm 12y ago
If it even remotely conforms to the spec I'd say that's gold. More often than not 'barely' translates into 'does not bear any resemblance to'.
stestagg 12y ago
Re 2) I've done this a few times. The trick is to ignore the detail of the spec, and understand what they actually want better than they do. If you get that right, then the actual coding becomes insignificant, and everyone is happy
colomon 12y ago
It's explicitly labeled a parable: "a simple story used to illustrate a lesson." It's not meant to be literally true. The second programmer's inexperience is just another reason why his boss judges his work to obviously have been easy.

ai_ja_nai 12y ago

This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold. Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are so notoriously dysfunctional: engineers want to produce art, while management wants to sell stuff to customers. 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. Lone cowboy programmers that can conjure working stuff in a minimum time are praised by management, and insulted by colleagues. And, since this parable was probably written by a disgruntled, good scholar engineer, I think this whole story is a little biased...

cshimmin 12y ago
I think you missed the point.
- vegabook 12y ago
  ...though the idea that "engineers want to produce art, while management wants to sell stuff" has a lot of truth, and does have oblique relevance to the post, in the sense that Charles' "goofing off" was about thinking about the best way to abstract the problem and write it elegantly and concisely.
- ai_ja_nai 12y ago
  tell me, please

scott_w 12y ago

If we pretend this was a real story, Charles'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's also pissing off his colleagues who will feel they're working to support a guy messing around. 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. 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'm speculating, the manager was looking to punish Charles for his behaviour and went about it completely the wrong way.

ricefield 12y ago
And that is why this is a parable—not a real story, and not intended to be read as one.

motters 12y ago

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't then it can get much more complex. It'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. However, for most non-trivial problems understanding everything up front isn't possible. To know what works you may need to create prototypes and iterate, abandoning things which don'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't work and the more formalised process might work better.

TheOtherHobbes 12y ago
The parable is really about the nature of corporate politics and the art of perception management. I'm not sure how obvious the underlying point is -> programming languages and methodologies are structured by political requirements. Programmer A is writing software. He knows nothing about perception management and status plays. Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status. The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it. IMO the interesting question is how much this applies to coding culture and language and OS design as a whole.
marcosdumay 12y ago
> However, for most non-trivial problems understanding everything up front isn't possible. You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems. That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.

rkachowski 12y ago

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. A does a thing, it takes a long time, solves the problem and he becomes System Analyst. C does a thing, it's shorter in both time and effort, and he leaves the company a year later. What about the value produced by the solution? It'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. 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. How about going forward in the story? A sequel-sequel? 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 "smart" that demonstrated their intelligence and worthiness of being rewarded - the problem specifications being nothing more than a means to achieving this. 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.

hotBacteria 12y ago

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected 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't have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy. So he works long hours to fix the situation, then he burns out. Source? This is somehow happened to me. Several times. This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It'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. I'd like to be Charles one day, but for now I'm Alan. [1] https://en.wikipedia.org/wiki/Death_march_(project_management) https://en.wikipedia.org/wiki/Death_march_(project_managemen...

alephnil 12y ago
If this story had happened in real life, and the problem had been more complicated than anticipated, and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed, so in that case the project would be likely to fail, or at least be severely delayed. However, Alan was making the problem more complicated by introducing a lot of accidental complexity, and I have often seen that this is done even when the problem is more complicated than anticipated. Such a project could easily create enough work for 10-15 people in the hypothetical scenario in the article if the project had enough necessary complexity to be a four person project. It is very hard to distinguish between what is necessary and accidental complexity, and that is precisely the point of the article. Prestige is very often bound to how many subordinates you have rather than how well you solve a particular task, so making your project artificially complex can be a strategy for climbing toward upper management. This may of cause be a conscious or unconscious from the employee/manager in question.
- jackweirdy 12y ago
  > ... and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed Not to mention, the company will be paying Alan and his team much more than they’re paying Charles. It’s my suspicion that people will give more weight to people they’re paying more, simply because they’re perceived as more valuable - independent of any other hard data. So despite having already spent more money on Alan, they’d be likely to continue doing so, due to the perception of hard work and the perceived value to the company.

eludwig 12y ago

I think it's actually a great little story because in the end, everyone got what they wanted. The lone programmer did his work, got paid for it and left, hopefully to find a company with a better fit. 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. Everyone seems to have taken what they needed and got what they wanted. 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.

edw519 12y ago

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.

raldi 12y ago
I don't understand; your numbers add up to 5400, not 300.
- lorenzk 12y ago
  Total lines of code kept increasing until he was able to refactor everything on Friday and cut them back down to 300.
- EliRivers 12y ago
  The final column isn't LoC written that day; it's LoC in total. Friday was spent refactoring (what we in the old days called "rewriting", before the hipsters made it cool); taking the code that was already working, and making it smaller, lighter, better.
  - frostmatthew 12y ago
    > what we in the old days called "rewriting", before the hipsters made it cool Calling it refactoring dates back to at least the early 90s[1], which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler[2]. [1] http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf [2] http://www.amazon.com/gp/product/0201485672 http://www.amazon.com/gp/product/0201485672

anodari 12y ago

I know it's a parable and the objective is to send the message that "customers value complexity". In the enterprise we see lots of news where a business spend millions in a certain solution and we sometimes think it was overspend. 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 'hello word' joke about programmer evolution. But at the same time, the novice, rarelly will deliver a good sollution in the first time. 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.

VLM 12y ago

The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political / economic reasons we sometimes have to pretend its a vocation or profession, but it really isn't in actual application. Software architecture should be in the "fine arts" department at university, not a branch of finance, engineering, or math. 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're a hopelessly tasteless neanderthal. The only time effort is rewarded in art is when parents watch their (own) kids perform. 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 "enterprise hello world" 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 "complicated functional block" takes maybe three hours long term total average, a "little bit less than before/after lunchhour", 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.

black_knight 12y ago
While software architecture certainly is an art, I would not say it is unique in that aspect among the fields you mentioned. Both engineering and maths should be considered art in their own rights. If you consider abstract mathematics, it is easily seen that many mathematicians find most of their inspiration in the aesthetics of their ideas. Somehow the way we teach maths obscures this fact from the students. Oh, and if you didn't already: Read «Zen and The Art of Motorcycle Maintenance». Aside from being a great story, it goes into detail about how technical work becomes art when done with Quality in mind.

jorjordandan 12y ago

A lot of people seem to think this is a story about programming. It's not. It'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 'soft skills' and will get you farther than a perfect understanding of monads.

danschumann 12y ago

If there is a second sequel to this story, it's that the one guy goes on to start a successful company, and the other guy is entrenched in the politics of his company. I think this would be a better comparison if space invaders was left out. Or perhaps if it were, "he scribbled for a while, then played space invaders, then scribbled some more.", as opposed to him starting with nothing but space invaders. The other guy began by inventing problems rather than solving them. It comes down to, a direct, though outwardly puzzling, solution that is apt VS. an indirect, political, frustrating(for everyone), bloated, slow solution. If it weren'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't seem so weird. The fact that people were catching on to this idea in 1985 is pretty striking. This is anecdotal and doesn't really teach the bigger picture. It's also not encouraging, as it doesn't lead the user to the correct path of action. It really needs a second sequel where the space invader guy goes on to be wildly successful to be a good story.

Periodic 12y ago

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 "enterprise programmer" while lionizing the young-but-inexperienced smart programmer. It's a very common theme here on HN. It'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. Let me address the parable a bit more directly. 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'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'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. I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn'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't say.

ploxiln 12y ago
This is indeed a comment-baity article. It is fiction, those two people didn't really exist and do those things. It gets programmers/developers riled up - because it's so believable. It is indeed the case that the characters are vastly different in terms of skill, and that is sort of the point. Alan did spend time developing his skills, but it was focused on frameworks and processes, and not effective programming or problem solving. Maybe he just didn't have the right start, didn't know what he didn't know, and just went the wrong way from there. But management, and Alan himself, can't tell the difference. I think that's the ultimate take-away. Non-programmers and "bad" programmers can't recognize good programming, even if they look at results. Well they can, but it takes a lot of time and luck to come across comparable situations. It seems like an intractable problem. They don't know who to trust; and there doesn't seem to be a way to find out for them, except to be genuinely good at developing software... but how to know which way to go about that?

moca 12y ago

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. 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). 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.

deleted 12y ago

[deleted]

kazinator 12y ago

I can see exactly where Charles went wrong. Here is how the story should have gone: 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. 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's team doesn't even comprehend, for instance, let alone management, without studying). In this case, nobody can dismiss the problem as being something easy that a junior programmer can solve, and Alan's team look like troglodytes from the Dark Ages. All the more so because their buggy, incomplete program is over 2500 lines, while Charles' language fits into 2300. :)

PhoenixWright 12y ago

I can't wait to get out of software development. I'm just a couple of years removed from uni and I'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. I'm not even thirty and I plan on retiring and starting my own business (tech or other) by the time I'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! It'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.

aidenn0 12y ago
This comment is more for others than for you, but there are good companies out there that are engineering focused. Almost none of them are corporations in which "software" is just one division of many,
tripzilch 12y ago
> It's a complete shame too because I enjoy solving problems through code. Who/what's there to stop you doing just that, once you have taken "the opportunity to take the money and run"?

gpvos 12y ago

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

collyw 12y ago

And if the specs change after the code was written (as usually happens in real life), who'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.

speby 12y ago

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's now retired or Professor Emeritus now, I believe.

rumcajz 12y ago

Rarely (unless you are working on your hobby project) you get a chance to make program simple. There are inherently complex requirements that can't be changed for political reasons, complex legacy interfaces to conform to et c. Interestingly, most programmers seem to think that inherent complexity doesn'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.