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.
>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.
I don't think that's a fair conclusion. There's much more going on here.
Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through this. It's pretty secure!" If the locksmith is done in 10 minutes, I think, "Holy shit! With the right tools and know-how, someone can completely bypass my security in ten minutes!" This isn't so shocking around here, because most people on HN know just how vulnerable most security systems can be. Many people will not have that knowledge and be comforted by a locksmith taking longer.
Also, when you hire a locksmith, you usually watch the locksmith do his work- either because you're locked out of something and have to stand around uselessly, or the guy is in your house and it shouldn't take too long. This makes you invested in his effort- if it takes an hour, you watched the locksmith work for an hour. It's hard not to pay, given that you saw how long it took, and how he was working at it.
The same standard doesn't seem to apply elsewhere- if my steak takes an hour rather than twenty minutes, I'm not going to pay more for it, I'm going to complain to the manager. If the oil change takes too long, I'm not going to be happy about that, either. If I buy a cabinet, I usually don't care if the carpenter took 10 hours or 20, I'm going to want to pay based on the quality of the cabinet.
I think your conclusion is true in some situations, but it's definitely not universal to all work.
This is the mechanic story all over:
Guy takes his car to a garage because it keeps breaking down, and the mechanic leans in and listens to the engine for a minute. He goes and gets a hammer and listens to the engine again, and then raps sharply on the engine casing. The engine goes back into sync and stops breaking down.
The mechanic says "that'll be £500, please." The guy's outraged: "But all you did was tap it!"
Mechanic replies "it was a pound for the tap, and £499 for knowing where to tap."
I have a different experience. Our heating broke on two (unrelated) occasions.
In the first case, the repairman came, fixed the thing in 20 minutes, seemed competent, and I gladly payed him.
In the second case, the company sent an inexperienced employee, who couldn't figure out the problem, and spent 2 hours trying everything before finally deciding the most expensive component needed to be replaced. I was very unsatisfied, especially since they charged me for all the seemingly pointless troubleshooting time.
So maybe it's not only important to make a lot of effort, but to also appear competent while working?
A couple of years ago, I locked myself out of the house. I called a locksmith, who showed up at the house surprisingly quickly.
After spending a number of minutes fiddling with some impressive-looking lock picks and exercising what must be years of learned skill, he couldn't unlock the door. Sheepishly, he put away the specific tools and pulled out a dummy key + a rubber mallet.
The locksmith put the dummy key into the lock tumbler, whacked it once on the head with the rubber mallet, and the door unlocked. From the time he produced the tools to the time I was inside the house was well under sixty seconds.
I thought, Why didn't he just do that in the first place? And concluded much the same as you've said -- $70 for thirty seconds of work might seem steep and some people need the song and dance. Personally, I was grateful to have on-demand service like that available so quickly :)
> 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.
It doesn't have to be amount of effort, even. In your example, the locksmith has so much experience, its easy for him to fix locks, so not much effort it required by him. But we do make this correlation between effort and time; so more time spent == more effort to our brain. That needs to change.
I have read somewhere (it could be apocryphal, although it makes sense) that for this very reason barbers tend to snip their scissors in the air a lot - to give off an impression that there's more work being done than there actually is...
It isn't totally irrational, it's merely measuring the only metric we can measure objectively, in the usual way it's measured. The fact the measurement function is exactly backwards is not obvious; in fact, it's entirely reasonable to expect to pay more for taking up more of someone's time.
Locks are actually a very good (pathologically good?) example of this, because we usually have no idea how well and how often they succeeded and a single failure can be catastrophic. Therefore, it's very hard to tell how good of a job the locksmith who installed or fixed it did without being a locksmith yourself. Compare cars: With a car, you drive it around pretty often, and you get a feel for how it handles and smells and sounds relative to the baseline established when you first got it. There's a constant evaluation of factors relevant to how the car is actually doing. With a lock, if the lock is put in well and functioning properly, the successful evaluations are mostly unnoticed unless you have a camera watching the lock 24/7.
I think it's more complicated than this Locksmith example. I think we are so used to being ripped off by "experts", many
with a lot of spinach behind their names; We start to think
everyone is trying to make the most amount of money they can
out of a situation(usually a bad situation). I have no problem paying someone for a job well done--if they do it
quick all the better. The problem I have encountered is the
expert did the job, but it was a half ass job and their mistake didn't show up until later. I'm now kind of jaded.
One other thing about experience. I have found experience
doesn't matter quite as much as I thought it did in a lot
of professions--especially the professions that are a mix
of science, and art--like medicine, and yes Programming. A little experience, but
still double checks their work, and is staying current--Gold mine! The pillar of their profession, with an ego to match--I run! (I noticed someone brought up the mechanic and the hammer story. A stuck pinion on a starter sometimes responds to
a hammer blow. I used to position a long dowel(broom handle)
on the stuck starter through the engine bay and whack the dowel with a hammer.) Oh yea, I have found that people who
don't overcharge(whatever that even means anymore) are well
liked amoung their peers, and customers.
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.
The way I see it: Charles made the problem look simple by spending a few months thinking about the whole program, while Alan made the same problem look complicated by writing a bunch of code and always looking busy.
While I agree that Charles is the exception, I don't believe meritocracy is a valid solution; I'll always bet on Charles:
If the project was actually a "3500 lines of code" problem, then Charles might have taken longer to think about it, but it's my experience that Alan never would have finished.
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.
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'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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
Green-field software should be well in excess of 5 lines a day. If the software is old to the point that nobody fully understands it any more, and previous maintainers have left the company, the number of production lines of code added per day may easily be lower than 5.
Older code has a lot more functionality, so every line of code is capable of leveraging more. 5 lines of code in a mature system may do more than 500 lines in a new system. But a bigger factor is figuring out which 5 lines to write. A third of the time can easily be spent researching the code trying to figure out a plan of attack, and the remainder iteratively debugging different variations of 5 lines validating (or invalidating) assumptions made about the code's emergent design during the planning phase.
And I'm not counting test code. Test code is usually cheap to write, if the code is testable. Writing lots of tests is an easy way to inflate lines written, should you be stuck somewhere in the dark ages where they actually measure productivity by such a discredited yardstick.
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.
In my experience, as an outrageously well paid programmer, I will touch a lot more than 5 lines a day whenever I am programming, especially if I include changes to the unit tests, integration tests and such. There are two caveats though:
First, you will not be coding every day. There's requirements gathering, setting up environments, build systems and such. Depending on what you are working on, this could be over 50% of your time.
And second, and perhaps more importantly, most of the lines you touch will replace lines that you, or someone else, has written in the past, instead of just adding more functionality without touching the existing codebase. For instance, 5 months ago I started working on a project that had been written by two junior programmers that did not understand the language they were using, functional programming, or the problem they were solving. The code was full of repetition, bugs, and there was no way to make heads or tails of what it was actually solving. So I started refactoring, working on eliminating duplication, and trying to build abstractions. After a week, I had made a good dozen commits every day, but they were on top of each other: total LOC actually went down. Only after that week of coding that didn't add to the codebase I could see the places where refactoring just wouldn't do anymore, and was able to figure out what to rewrite, and how to add the additional requirements.
So I had spent a month on a 15K LOC codebase, and ended up with 12K LOC that did more, had more tests, ran faster, and made sense to the people that would end up owning the product in the long term. But yes, I mucked with over 100 lines of code most days.
Situations like that happen to experienced programmers all the time.
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.
For me, lines of code per day varies depending on what is being done and how.
If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day.
On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable.
This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).
Remember that you will spend more time debugging, documenting and testing your code. And this is if you work somewhere that doesn't expect you to spend 10+ hours a week in meetings.
[edit]
And you will also write a lot of code you throw away; sometimes you need to solve 90% of the problem the wrong way to discover the right way.
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.
[+] [-] anaolykarpov|11 years ago|reply
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.
[+] [-] Hasu|11 years ago|reply
I don't think that's a fair conclusion. There's much more going on here.
Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through this. It's pretty secure!" If the locksmith is done in 10 minutes, I think, "Holy shit! With the right tools and know-how, someone can completely bypass my security in ten minutes!" This isn't so shocking around here, because most people on HN know just how vulnerable most security systems can be. Many people will not have that knowledge and be comforted by a locksmith taking longer.
Also, when you hire a locksmith, you usually watch the locksmith do his work- either because you're locked out of something and have to stand around uselessly, or the guy is in your house and it shouldn't take too long. This makes you invested in his effort- if it takes an hour, you watched the locksmith work for an hour. It's hard not to pay, given that you saw how long it took, and how he was working at it.
The same standard doesn't seem to apply elsewhere- if my steak takes an hour rather than twenty minutes, I'm not going to pay more for it, I'm going to complain to the manager. If the oil change takes too long, I'm not going to be happy about that, either. If I buy a cabinet, I usually don't care if the carpenter took 10 hours or 20, I'm going to want to pay based on the quality of the cabinet.
I think your conclusion is true in some situations, but it's definitely not universal to all work.
[+] [-] iamwithnail|11 years ago|reply
The mechanic says "that'll be £500, please." The guy's outraged: "But all you did was tap it!"
Mechanic replies "it was a pound for the tap, and £499 for knowing where to tap."
Edit: Crap, beaten to it.
[+] [-] jakobegger|11 years ago|reply
In the first case, the repairman came, fixed the thing in 20 minutes, seemed competent, and I gladly payed him.
In the second case, the company sent an inexperienced employee, who couldn't figure out the problem, and spent 2 hours trying everything before finally deciding the most expensive component needed to be replaced. I was very unsatisfied, especially since they charged me for all the seemingly pointless troubleshooting time.
So maybe it's not only important to make a lot of effort, but to also appear competent while working?
[+] [-] rachelbythebay|11 years ago|reply
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.
[+] [-] MRSallee|11 years ago|reply
After spending a number of minutes fiddling with some impressive-looking lock picks and exercising what must be years of learned skill, he couldn't unlock the door. Sheepishly, he put away the specific tools and pulled out a dummy key + a rubber mallet.
The locksmith put the dummy key into the lock tumbler, whacked it once on the head with the rubber mallet, and the door unlocked. From the time he produced the tools to the time I was inside the house was well under sixty seconds.
I thought, Why didn't he just do that in the first place? And concluded much the same as you've said -- $70 for thirty seconds of work might seem steep and some people need the song and dance. Personally, I was grateful to have on-demand service like that available so quickly :)
[+] [-] SixSigma|11 years ago|reply
http://www.snopes.com/business/genius/where.asp
[+] [-] bottled_poe|11 years ago|reply
[+] [-] Iv|11 years ago|reply
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.
[+] [-] pm90|11 years ago|reply
[+] [-] V-2|11 years ago|reply
[+] [-] cbd1984|11 years ago|reply
Locks are actually a very good (pathologically good?) example of this, because we usually have no idea how well and how often they succeeded and a single failure can be catastrophic. Therefore, it's very hard to tell how good of a job the locksmith who installed or fixed it did without being a locksmith yourself. Compare cars: With a car, you drive it around pretty often, and you get a feel for how it handles and smells and sounds relative to the baseline established when you first got it. There's a constant evaluation of factors relevant to how the car is actually doing. With a lock, if the lock is put in well and functioning properly, the successful evaluations are mostly unnoticed unless you have a camera watching the lock 24/7.
[+] [-] marincounty|11 years ago|reply
[+] [-] hotBacteria|11 years ago|reply
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_managemen...
[+] [-] geocar|11 years ago|reply
While I agree that Charles is the exception, I don't believe meritocracy is a valid solution; I'll always bet on Charles:
If the project was actually a "3500 lines of code" problem, then Charles might have taken longer to think about it, but it's my experience that Alan never would have finished.
[+] [-] alephnil|11 years ago|reply
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.
[+] [-] wting|11 years ago|reply
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...
[1] http://www.win.tue.nl/~wstomv/quotes/software-requirements-s...
[+] [-] akamaka|11 years ago|reply
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.
[+] [-] jakobegger|11 years ago|reply
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.
[+] [-] colomon|11 years ago|reply
[+] [-] stestagg|11 years ago|reply
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
[+] [-] edw519|11 years ago|reply
[+] [-] raldi|11 years ago|reply
[+] [-] Periodic|11 years ago|reply
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|11 years ago|reply
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?
[+] [-] jorjordandan|11 years ago|reply
[+] [-] rkachowski|11 years ago|reply
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.
[+] [-] anodari|11 years ago|reply
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.
[+] [-] beloch|11 years ago|reply
[+] [-] danschumann|11 years ago|reply
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.
[+] [-] webreac|11 years ago|reply
[+] [-] jarcane|11 years ago|reply
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 ...
[+] [-] kazinator|11 years ago|reply
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.
:)
[+] [-] rumcajz|11 years ago|reply
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.
[+] [-] sidcool|11 years ago|reply
[+] [-] moca|11 years ago|reply
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.
[+] [-] motters|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] jebediah|11 years ago|reply
[+] [-] barrkel|11 years ago|reply
Older code has a lot more functionality, so every line of code is capable of leveraging more. 5 lines of code in a mature system may do more than 500 lines in a new system. But a bigger factor is figuring out which 5 lines to write. A third of the time can easily be spent researching the code trying to figure out a plan of attack, and the remainder iteratively debugging different variations of 5 lines validating (or invalidating) assumptions made about the code's emergent design during the planning phase.
And I'm not counting test code. Test code is usually cheap to write, if the code is testable. Writing lots of tests is an easy way to inflate lines written, should you be stuck somewhere in the dark ages where they actually measure productivity by such a discredited yardstick.
[+] [-] javert|11 years ago|reply
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.
[+] [-] hibikir|11 years ago|reply
First, you will not be coding every day. There's requirements gathering, setting up environments, build systems and such. Depending on what you are working on, this could be over 50% of your time.
And second, and perhaps more importantly, most of the lines you touch will replace lines that you, or someone else, has written in the past, instead of just adding more functionality without touching the existing codebase. For instance, 5 months ago I started working on a project that had been written by two junior programmers that did not understand the language they were using, functional programming, or the problem they were solving. The code was full of repetition, bugs, and there was no way to make heads or tails of what it was actually solving. So I started refactoring, working on eliminating duplication, and trying to build abstractions. After a week, I had made a good dozen commits every day, but they were on top of each other: total LOC actually went down. Only after that week of coding that didn't add to the codebase I could see the places where refactoring just wouldn't do anymore, and was able to figure out what to rewrite, and how to add the additional requirements.
So I had spent a month on a 15K LOC codebase, and ended up with 12K LOC that did more, had more tests, ran faster, and made sense to the people that would end up owning the product in the long term. But yes, I mucked with over 100 lines of code most days.
Situations like that happen to experienced programmers all the time.
[+] [-] patrickmay|11 years ago|reply
[+] [-] f2f|11 years ago|reply
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.
[+] [-] jqm|11 years ago|reply
If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day.
On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable.
This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).
[+] [-] aidenn0|11 years ago|reply
[edit] And you will also write a lot of code you throw away; sometimes you need to solve 90% of the problem the wrong way to discover the right way.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] swatow|11 years ago|reply
[+] [-] eludwig|11 years ago|reply
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.