91–100 of 169 posts
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.
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…
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…
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.
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.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 h…
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 introdu…
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.
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 single developer outperforming a team is not that far-fetched - under ideal circumstances. It is obvious that there is a lot of overhead from communicating and coordination in team development, and the biggest drop in efficiency is scaling from a single developer to a small team. If a project is just small enough that a single developer can handle it, it is clearly the most efficient. The problem is that the lone-developer approach is totally non-scalable. If it turns out halfway through the project that it will require 20% more work than originally estimated, then the lone developer will have to add two or three colleges at a late stage - and since there is no written spec, the project is probably going to end up being even later and bad quality code. But of course this is not considered in a parable written to show that the lone coder-approach is superior.
Also the 5 factor difference in lines of code and bug count for solving the same problem is not far fetched either. But I think it has nothing to do with the number of developers but rather on culture and competency. It might just as well be the lone developer who writes a lot of bad code to solve a simple problem. Of course it could be a very competent single developer compared to a team of mediocre programmers, but it could just as well be the other way around. And in a team development effort, the most competent developer may perform code reviews and so on, so the overall code quality is better than just the average competency of the developers on the team.
The major difference in the two approaches in the parable is that the one team actually produces a written problem analysis and spec, while the cowboy has it all in his head. The story suggest that the lone developer actually produces a perfect problem analysis and is therefore able the write the perfect program without the overhead of producing written spec. However, the boss/customer have no way of knowing until the program is finished. If there was an error or miscommunication in developing the problem analysis, it is too late to change now, or at least will be much more costly than if it was discovered in the specification stage. Also, in the real world it requires communication with the customer to develop and verify the spec. It the story the development happens completely without outside input, which almost never happens in the real word. Even if developers would wish it was the case.
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.
Earlier quoted context omitted.
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!" M…
Experience pays in other professions that require competency, though: a surgeon who can proficiently perform a bypass in a short amount of time is far more valuable than a fresh graduate who potters around in there for a while. No one ever complains that a surgeon finished too quickly.
Another interesting issue is she shopped for a GP a long time ago, the GP referred her to specialist who referred her to the surgeon, can't have much of a marketplace if the participants aren't making any decisions. The only decision she made was a decade ago she picked the guy who referred her to the guy who referred her to a surgeon.
The craziest part of a crazy "market" or whatever you want to call it, is it mostly works. Something this screwed up should predictably kill everyone involved, but most of the time, it works, other than blowing a lot of money. It is the truly shocking part of the situation, at least from a "free market capitalism is the only system that, in practice, actually works" mantra. Maybe that's not so true, given the observational evidence.
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…
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!" M…
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 h…
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.