8 ms·

Is Good Code Impossible?

94 points by fogus 16y ago

Cabal 16y ago
What kind of professional accepts a contract without a clearly defined scope of work? The author repeatedly talks about quality work, but I'm not sure he knows what that means. It sounds like the Big Company had a sucker on their hands, and they knew it.
phaedrus 16y ago
His story will resonate with anyone who's written software for business. At my very first "real" programming job, my boss thought that this was how you motivate programmers - take whatever the real deadline is and cut the time in half, on the theory that the programmers will take twice as long as you give them anyway. I was pretty upset by this, because by being lied to about what the real timeframe was, we made a number of unsound technical decisions thinking we didn't have time to do things right. I don't think being lied to caused us to magically be able to get an app out the door faster - what being lied to about the schedule actually caused was for us to produce code that wasn't a good foundation for future changes.
- jacquesm 16y ago
  In practice though, given twice the amount of time there will not magically be a twice as good solution. And many times you'd find that the solution would actually be exactly the same. Give me 24 hours to do a job and I'll do it, give me two weeks and I'll procrastinate for 13 days and then do it in the last 24 hours. That's exaggerating, but not by much and I'm not sure I like to know myself that much.
- ido 16y ago
  I think I had the same boss as you in my first "real" job...Thankfully the experience taught me to choose my employers more wisely in all subsequent jobs.
- elviejo 16y ago
  This is a big dilemma for me. Because shouldn't making the code the right way be faster?... This is something that gave me grief for a long time until I realized that I was thinking about running a marathon not a sprint.
patio11 16y ago
Do they not teach Defense against the Dark Arts at university these days? "We can incorporate that new feature, boss. What feature do you want me to cut? I can get you expiring coupons but the store locator will have to go. Your call, you get paid the big money to make the important decisions."
- jacquesm 16y ago
  Joe Newbie says he can do it, why can't you. By the way you're up for your annual review next week, maybe you can find some time somewhere because this feature is sorely needed ;) Big companies have their own way of dealing with that sort of thing, you might get away with it in a company where there are not enough people waiting to take your place (sometimes literally). And you can only pull that one so often before it starts to look like you're using it as a way to slack. Maybe a better way to do this would be to say you'd do both but it will have a such-and-such effect on the deadline we all agreed on when taking on this project. That way you don't have to make it seem as though there is only a 'you can't have both' solution. The other side of this coin is that any programmer will normally speaking use all the ram, storage, run time, CPU cycles and wall clock time available to implement something. And make sure you do that in email, not verbally. Office politics like this is one of the bigger reasons why you won't find the best-of-breed programmers in offices like that, or at least not for long.
  - jasonkester 16y ago
    "Joe Newbie says he can do it, why can't you?" "Other people's inability to do basic project estimation has no bearing on the issue at hand." Why is software the only field where people allow themselves to be bullied into ignoring basic arithmetic? I was in a kitchen shop the other day, and the sales guy had no problem rearranging things to modify the final price, but there was a list of components in front of us at all times, broken down by price. Pick and choose what you want. That's exactly how software estimation works too. If you add something to the scope, it gets added to the budget. There's simply no room to do otherwise.
    - 16y ago
msie 16y ago
This is destined to be a classic. Well written and so true. It's a better version of the tale I tell my friends about my line of work. I wonder if forwarding it to my non-coding partner will make any difference?
johnfn 16y ago
This was a pretty funny story. I was kind of disappointed that it never got into the area that I was really interested, though: that of writing clean, maintainable, "good" code.
milesf 16y ago
All coders should be schooled in the arts of negotiation. Sustainable pace is the only environment I will work in. If a boss or customer is pushing for a new feature, the answer is to cut something else. Just because they want it doesn't mean they must have it. "But I might lose my job! But they might think I'm an amateur! But they... but...". No. Sustainable pace means working reasonably. Yes, there will always be others willing to say yes to everything and work insane hours. And they will continue to write crap code. You've heard the old adage "Good, fast, or cheap. Pick two". Mine is "Good, fast, or cheap. Pick one, and it better be Good".
lindvall 16y ago
It's a shame he got himself into this situation. I think more people need to realize that if you can only win a project by killing yourself, it isn't worth winning. So what if it means someone else gets the gig — it wouldn't have been worth it if that's what it took. Also, if think copying-and-pasting code and forgoing defining constants are tricks that will save you time, You're Doing It Wrong.
binaryfinery 16y ago
He made his bed.
praptak 16y ago
Haha, it is so funny when it happens to other people.
whereas 16y ago
I think that only when you have a very clear idea what the code is to do, it will be good. Bad code is what you write the rest of the time.
st0p 16y ago
With all due respect, I think he failed horribly. How can you accept a project due in two weeks, and then afterwards learn about the basic requirements? If you're so obsessed with 'clean code' (a concept i doubt if it even exists), how can you miss out on software engineering basics like requirements gathering?
- gaius 16y ago
  Because most of the people who buy (anything) are not professional (anything) buyers. I've shot a few weddings and to make a viable business out of it and do quality work, you need to charge about a grand per wedding. Probably more, depending on various factors. Really, that's just how the numbers work out. One reason the wedding photography business is so tough is that the people who buy your services have no idea what's involved (all told, it's 30-40 hours work, once you have your workflow down, using fairly expensive equipment) and balk at even half that. Esp. since their friend with his first "prosumer" camera has told them he can do it for a tenth of that[1], and they're being ripped off. So the question really is, how much do you need the work? [1] He can't; he is in fact committing himself to giving the happy couple those 30-40 hours of his time as a wedding present. But he won't know that 'til it's too late...
- fauigerzigerk 16y ago
  Please tell me where those software engineering basics are written down. I'd really like to learn how to deal with clients that come up with new requirements along the way on a two week project with a hard deadline. That's not an engineering problem I'm afraid.
jsn 16y ago
The question is, was it worth it? Did he get paid enough to feel well compensated for his frustration? If yes, then why all the venting? And if the answer is no: You should always be ready to walk away from the deal. You don't have to accept unrealistic deadlines. If you choose to accept them, though, you don't have to allow massive spec changes midway. If you choose to allow it, you better make sure the money is good enough to compensate you for the massive horrible burnout you're going to put yourself through. And if you don't -- well, who else is to blame here? When you take a lot of risks, you get burned sooner or later. Don't make bets if you can't afford to lose them.
gaius 16y ago
The Clients Never Care As Much As You Do A valuable lesson indeed. Things to remember: 1) your client isn't spending their own money 2) if it goes well, they get the credit 3) if it fails, you take the blame. Point (4) that I learned in the consulting business is, it's nothing personal. Part of your fee covers "scapegoat for hire". You're just an actor playing a role. You'll never run into those guys again, and it has no bearing on you getting work from that organization in the future.
defdac 16y ago
My code is only good until someone rewrites it and makes it better. I can make my code easy to read and follow and do what it is supposed to do, and thus easy to rewrite. That is good code. Good code is definitely not something intricately made by some Golden Design Pattern Rule argumented by a wise ass for hours just because he or she thinks his way/code is the best. That will on the contrary, and with high certainty, result in really crappy code. Programming is not science, it's more like art - with one big difference. Code can be written to be easy to modify by other artists afterwards to their liking. If these artists can't modify or read other peoples code, but have to rewrite it completely there is a really big probability their new code is that of a newbie. It might be fancy and intricate, but still made by someone that lacks the ability to read, follow and understand old code. Someone that can't understand "crappy" code, probably have a hard time even understanding design patterns - and have probably spent alot of time studying design patterns and memorized all their fancy names..
brown9-2 16y ago
I spent those eight days writing code in a fury. I used all the tools available to me to get it done: copy-and-paste (AKA re-usable code), magic numbers (avoiding the duplication of defining constants and then, gasp!, retyping them), and absolutely NO unit tests! (Who needs red bars at a time like this, it’d just demotivate me!) I don't understand why any of these are time-savers. Each of these tasks are things that might take you a few extra minutes now, but generally save far greater amounts of time almost immediately. The example used in this article to come to the conclusion that "good code is impossible" is quite contrived. Of course you are going to end up with a shitty application and experience when you are 1) given almost no time to produce 2) given no technical help by the client 3) given no support by the client.
- ido 16y ago
  I think it was meant in jest.
terra_t 16y ago
Friends don't let friends work in job shops. The fundamental problems aren't about code, they're in project management. Job shops occasionally strike a good balance, but inevitably bad clients drive out the good clients. From time to time I think about a business model that works a lot like a job shop but tries to build equity in a software product line, learning from experience, continuous improvement, all that... But then I look at my 'sunk costs' and how I can get them back quickly to pay for my vision and I see the need for a 'moon shot' that maximizes the revenue I can get in the medium term... That's life, I guess.
damoncali 16y ago
Three words: Out Of Scope

94 points by fogus 16y ago

Cabal 16y ago

What kind of professional accepts a contract without a clearly defined scope of work? The author repeatedly talks about quality work, but I'm not sure he knows what that means. It sounds like the Big Company had a sucker on their hands, and they knew it.

phaedrus 16y ago

His story will resonate with anyone who's written software for business. At my very first "real" programming job, my boss thought that this was how you motivate programmers - take whatever the real deadline is and cut the time in half, on the theory that the programmers will take twice as long as you give them anyway. I was pretty upset by this, because by being lied to about what the real timeframe was, we made a number of unsound technical decisions thinking we didn't have time to do things right. I don't think being lied to caused us to magically be able to get an app out the door faster - what being lied to about the schedule actually caused was for us to produce code that wasn't a good foundation for future changes.

jacquesm 16y ago
In practice though, given twice the amount of time there will not magically be a twice as good solution. And many times you'd find that the solution would actually be exactly the same. Give me 24 hours to do a job and I'll do it, give me two weeks and I'll procrastinate for 13 days and then do it in the last 24 hours. That's exaggerating, but not by much and I'm not sure I like to know myself that much.
ido 16y ago
I think I had the same boss as you in my first "real" job...Thankfully the experience taught me to choose my employers more wisely in all subsequent jobs.
elviejo 16y ago
This is a big dilemma for me. Because shouldn't making the code the right way be faster?... This is something that gave me grief for a long time until I realized that I was thinking about running a marathon not a sprint.

patio11 16y ago

Do they not teach Defense against the Dark Arts at university these days? "We can incorporate that new feature, boss. What feature do you want me to cut? I can get you expiring coupons but the store locator will have to go. Your call, you get paid the big money to make the important decisions."

jacquesm 16y ago
Joe Newbie says he can do it, why can't you. By the way you're up for your annual review next week, maybe you can find some time somewhere because this feature is sorely needed ;) Big companies have their own way of dealing with that sort of thing, you might get away with it in a company where there are not enough people waiting to take your place (sometimes literally). And you can only pull that one so often before it starts to look like you're using it as a way to slack. Maybe a better way to do this would be to say you'd do both but it will have a such-and-such effect on the deadline we all agreed on when taking on this project. That way you don't have to make it seem as though there is only a 'you can't have both' solution. The other side of this coin is that any programmer will normally speaking use all the ram, storage, run time, CPU cycles and wall clock time available to implement something. And make sure you do that in email, not verbally. Office politics like this is one of the bigger reasons why you won't find the best-of-breed programmers in offices like that, or at least not for long.
- jasonkester 16y ago
  "Joe Newbie says he can do it, why can't you?" "Other people's inability to do basic project estimation has no bearing on the issue at hand." Why is software the only field where people allow themselves to be bullied into ignoring basic arithmetic? I was in a kitchen shop the other day, and the sales guy had no problem rearranging things to modify the final price, but there was a list of components in front of us at all times, broken down by price. Pick and choose what you want. That's exactly how software estimation works too. If you add something to the scope, it gets added to the budget. There's simply no room to do otherwise.
  - 16y ago

msie 16y ago

This is destined to be a classic. Well written and so true. It's a better version of the tale I tell my friends about my line of work. I wonder if forwarding it to my non-coding partner will make any difference?

johnfn 16y ago

This was a pretty funny story. I was kind of disappointed that it never got into the area that I was really interested, though: that of writing clean, maintainable, "good" code.

milesf 16y ago

All coders should be schooled in the arts of negotiation. Sustainable pace is the only environment I will work in. If a boss or customer is pushing for a new feature, the answer is to cut something else. Just because they want it doesn't mean they must have it. "But I might lose my job! But they might think I'm an amateur! But they... but...". No. Sustainable pace means working reasonably. Yes, there will always be others willing to say yes to everything and work insane hours. And they will continue to write crap code. You've heard the old adage "Good, fast, or cheap. Pick two". Mine is "Good, fast, or cheap. Pick one, and it better be Good".

lindvall 16y ago

It's a shame he got himself into this situation. I think more people need to realize that if you can only win a project by killing yourself, it isn't worth winning. So what if it means someone else gets the gig — it wouldn't have been worth it if that's what it took. Also, if think copying-and-pasting code and forgoing defining constants are tricks that will save you time, You're Doing It Wrong.

binaryfinery 16y ago

He made his bed.

praptak 16y ago

Haha, it is so funny when it happens to other people.

whereas 16y ago

I think that only when you have a very clear idea what the code is to do, it will be good. Bad code is what you write the rest of the time.

st0p 16y ago

With all due respect, I think he failed horribly. How can you accept a project due in two weeks, and then afterwards learn about the basic requirements? If you're so obsessed with 'clean code' (a concept i doubt if it even exists), how can you miss out on software engineering basics like requirements gathering?

gaius 16y ago
Because most of the people who buy (anything) are not professional (anything) buyers. I've shot a few weddings and to make a viable business out of it and do quality work, you need to charge about a grand per wedding. Probably more, depending on various factors. Really, that's just how the numbers work out. One reason the wedding photography business is so tough is that the people who buy your services have no idea what's involved (all told, it's 30-40 hours work, once you have your workflow down, using fairly expensive equipment) and balk at even half that. Esp. since their friend with his first "prosumer" camera has told them he can do it for a tenth of that[1], and they're being ripped off. So the question really is, how much do you need the work? [1] He can't; he is in fact committing himself to giving the happy couple those 30-40 hours of his time as a wedding present. But he won't know that 'til it's too late...
fauigerzigerk 16y ago
Please tell me where those software engineering basics are written down. I'd really like to learn how to deal with clients that come up with new requirements along the way on a two week project with a hard deadline. That's not an engineering problem I'm afraid.

jsn 16y ago

The question is, was it worth it? Did he get paid enough to feel well compensated for his frustration? If yes, then why all the venting? And if the answer is no: You should always be ready to walk away from the deal. You don't have to accept unrealistic deadlines. If you choose to accept them, though, you don't have to allow massive spec changes midway. If you choose to allow it, you better make sure the money is good enough to compensate you for the massive horrible burnout you're going to put yourself through. And if you don't -- well, who else is to blame here? When you take a lot of risks, you get burned sooner or later. Don't make bets if you can't afford to lose them.

gaius 16y ago

The Clients Never Care As Much As You Do A valuable lesson indeed. Things to remember: 1) your client isn't spending their own money 2) if it goes well, they get the credit 3) if it fails, you take the blame. Point (4) that I learned in the consulting business is, it's nothing personal. Part of your fee covers "scapegoat for hire". You're just an actor playing a role. You'll never run into those guys again, and it has no bearing on you getting work from that organization in the future.

defdac 16y ago

My code is only good until someone rewrites it and makes it better. I can make my code easy to read and follow and do what it is supposed to do, and thus easy to rewrite. That is good code. Good code is definitely not something intricately made by some Golden Design Pattern Rule argumented by a wise ass for hours just because he or she thinks his way/code is the best. That will on the contrary, and with high certainty, result in really crappy code. Programming is not science, it's more like art - with one big difference. Code can be written to be easy to modify by other artists afterwards to their liking. If these artists can't modify or read other peoples code, but have to rewrite it completely there is a really big probability their new code is that of a newbie. It might be fancy and intricate, but still made by someone that lacks the ability to read, follow and understand old code. Someone that can't understand "crappy" code, probably have a hard time even understanding design patterns - and have probably spent alot of time studying design patterns and memorized all their fancy names..

brown9-2 16y ago

I spent those eight days writing code in a fury. I used all the tools available to me to get it done: copy-and-paste (AKA re-usable code), magic numbers (avoiding the duplication of defining constants and then, gasp!, retyping them), and absolutely NO unit tests! (Who needs red bars at a time like this, it’d just demotivate me!) I don't understand why any of these are time-savers. Each of these tasks are things that might take you a few extra minutes now, but generally save far greater amounts of time almost immediately. The example used in this article to come to the conclusion that "good code is impossible" is quite contrived. Of course you are going to end up with a shitty application and experience when you are 1) given almost no time to produce 2) given no technical help by the client 3) given no support by the client.

ido 16y ago
I think it was meant in jest.

terra_t 16y ago

Friends don't let friends work in job shops. The fundamental problems aren't about code, they're in project management. Job shops occasionally strike a good balance, but inevitably bad clients drive out the good clients. From time to time I think about a business model that works a lot like a job shop but tries to build equity in a software product line, learning from experience, continuous improvement, all that... But then I look at my 'sunk costs' and how I can get them back quickly to pay for my vision and I see the need for a 'moon shot' that maximizes the revenue I can get in the medium term... That's life, I guess.

damoncali 16y ago

Three words: Out Of Scope