Comments on: How not to Get Things Done [...] How not to get things done. This ironic post makes a case against those engineers with a knack for ‘getting things done’ usually at any price (e.g. gratuitous hacking) can be dangerous to the project.  All engineers require leadership on code quality, testing and maintenance not just those who get things done. [...] [...] How not to get things done. This ironic post makes a case against those engineers with a knack for ‘getting things done’ usually at any price (e.g. gratuitous hacking) can be dangerous to the project.  All engineers require leadership on code quality, testing and maintenance not just those who get things done. [...]

]]>
By: Ben Carter/2011/03/19/how-not-to-get-things-done/#comment-1852 Ben Carter Mon, 21 Mar 2011 23:36:44 +0000 <blockquote cite="James Podesta"> There is another type of coder, that may be getting mixed into the fray here. There is a type of coder, that, when faced with a problem, will take the first solution that pops to mind that addresses the immediate problem, while the rest of us will spend some time pondering the 3 or 4 other ways we could solve that problem. This “fast coder” generates code like this ALL the time, not just before milestones, and the code generally a mess of bandaids because these “bandaids” seem to solve his immediate problems. This is not a “fixer” but can look like one… be afraid. </blockquote> I think that is exactly what is going on here, and I think the fact that the original author cannot or will not tell the difference between these two types of coders makes me completely throw out his argument. I am a "fast-coder" in that, I will rapidly write code that solves a problem but will also test and evaluate all side effects of that problem when time permits. So that means when it's crunch time, and you turn off the extra checks, the feature still ships. All the rest of the time, you're just a hard-nosed problem solver who sometimes has to spend extra time fixing their own solutions ;o)

There is another type of coder, that may be getting mixed into the fray here. There is a type of coder, that, when faced with a problem, will take the first solution that pops to mind that addresses the immediate problem, while the rest of us will spend some time pondering the 3 or 4 other ways we could solve that problem. This “fast coder” generates code like this ALL the time, not just before milestones, and the code generally a mess of bandaids because these “bandaids” seem to solve his immediate problems. This is not a “fixer” but can look like one… be afraid.

I think that is exactly what is going on here, and I think the fact that the original author cannot or will not tell the difference between these two types of coders makes me completely throw out his argument.

I am a “fast-coder” in that, I will rapidly write code that solves a problem but will also test and evaluate all side effects of that problem when time permits. So that means when it’s crunch time, and you turn off the extra checks, the feature still ships. All the rest of the time, you’re just a hard-nosed problem solver who sometimes has to spend extra time fixing their own solutions ;o)

]]>
By: Peter Christensen/2011/03/19/how-not-to-get-things-done/#comment-1842 Peter Christensen Mon, 21 Mar 2011 18:18:31 +0000

If you want something done properly, kill anyone who might Get Things Done before you start.

I so agree. I know there are caveats and clarifications to it, but its core is so important that I’m willing to overlook them. There are many programmers who think the job is done when the feature works and nothing else has crashed in the meantime. That short-sighted view of software engineering can absolutely make or break a project, and it only takes one such programmer to introduce the risk.

]]>
By: ccpizz/2011/03/19/how-not-to-get-things-done/#comment-1837 ccpizz Mon, 21 Mar 2011 15:45:48 +0000 Agree with all this. In my experience, the code getting "fixed" is the problem, not the fixer. Generally if the code needs a last minute "dirty fix" it is because it is overcomplex, under-commented and/or the design of the original code was flawed. A good fixer will generally have a basic idea of the danger of the fix and will alert everyone to that end and what things they should give extra QA'ing to. At that point the lead and the producers will generally make a judgement call that the quick fix is needed for the milestone and will be addressed later. There is another type of coder, that may be getting mixed into the fray here. There is a type of coder, that, when faced with a problem, will take the first solution that pops to mind that addresses the immediate problem, while the rest of us will spend some time pondering the 3 or 4 other ways we could solve that problem. This "fast coder" generates code like this ALL the time, not just before milestones, and the code generally a mess of bandaids because these "bandaids" seem to solve his immediate problems. This is not a "fixer" but can look like one... be afraid. Agree with all this.

In my experience, the code getting “fixed” is the problem, not the fixer.

Generally if the code needs a last minute “dirty fix” it is because it is overcomplex, under-commented and/or the design of the original code was flawed.

A good fixer will generally have a basic idea of the danger of the fix and will alert everyone to that end and what things they should give extra QA’ing to. At that point the lead and the producers will generally make a judgement call that the quick fix is needed for the milestone and will be addressed later.

There is another type of coder, that may be getting mixed into the fray here. There is a type of coder, that, when faced with a problem, will take the first solution that pops to mind that addresses the immediate problem, while the rest of us will spend some time pondering the 3 or 4 other ways we could solve that problem. This “fast coder” generates code like this ALL the time, not just before milestones, and the code generally a mess of bandaids because these “bandaids” seem to solve his immediate problems. This is not a “fixer” but can look like one… be afraid.

]]>
By: Ben Carter/2011/03/19/how-not-to-get-things-done/#comment-1804 Ben Carter Sun, 20 Mar 2011 14:53:53 +0000 Well, clearly I was over-exaggerating when I suggested there was a necessity to kill anyone to solve the problem. Incapacitating them sufficiently that they can't use a keyboard is also a perfectly viable option... <grin> More seriously, though, I wasn't trying to suggest that the blame should always lie with the programmer who is actually doing the work - it can equally be the people who wrote the code in the first place, or management, or even some completely external factor (e.g. "our publisher just told us they need a demo of this for next week"). I've been exactly the person doing the hacking in more instances than I care to recall, too. The reason I wrote this article is that, whatever the cause, it's a pattern I've seen come up quite frequently, and it often seems to get overlooked just how dangerous it really is... just as much as I'm not pretending to give an exhaustive list of the reasons it happens, this also isn't a how-to guide on fixing it. It's a lighthearted invitation for people to be more aware of the issue, and try and head it off in whatever manner is appropriate to their situation. Well, clearly I was over-exaggerating when I suggested there was a necessity to kill anyone to solve the problem. Incapacitating them sufficiently that they can’t use a keyboard is also a perfectly viable option… <grin>

More seriously, though, I wasn’t trying to suggest that the blame should always lie with the programmer who is actually doing the work – it can equally be the people who wrote the code in the first place, or management, or even some completely external factor (e.g. “our publisher just told us they need a demo of this for next week”). I’ve been exactly the person doing the hacking in more instances than I care to recall, too.

The reason I wrote this article is that, whatever the cause, it’s a pattern I’ve seen come up quite frequently, and it often seems to get overlooked just how dangerous it really is… just as much as I’m not pretending to give an exhaustive list of the reasons it happens, this also isn’t a how-to guide on fixing it. It’s a lighthearted invitation for people to be more aware of the issue, and try and head it off in whatever manner is appropriate to their situation.

]]>
By: Christer/2011/03/19/how-not-to-get-things-done/#comment-1802 Christer Sun, 20 Mar 2011 14:09:45 +0000 We duct tape coders or fixers or however you might call us aren't the cause of the problem - we just apply a certain skill when a problem already happend. No matter wether one likes us or not - we're doing this not just randomly out of the blue or the evilness of our hearts to make your life miserable but in cases when we're asked to "fix things". We aren't the one causing the tight deadlines or the total lack of proper project management. We aren't the ones who fail to see IN TIME a drowning project and rescue it while there is time. We also usally warn beforehand that this is going to be ugly if we get unleashed two days before delivery. It's also usally not our fault not (yet) having the understanding of the entire system - how could we within two days? We get thrown (just happened to me last month) onto a project 6 days before deadline and we get chosen BECAUSE the deadline is to be kept and someone else failed to keep it for whatever reason. This is a management decision and not our own. Usally, our understanding is pretty good for the amount of time available - how could we get blamed for NOT having more understanding of the underlying architecture? If there even is any design or architecture to speak of - half of you obviously assumes always sitting in front of well designed, properly crafted code. Yours might be - the code we see and have to fix, often (usally) isn't proper or well designed. Otherwise, we wouldn't get called anyways if everything would be in order. We're the idiots who get up at three in the night because some system broke down and before the start of the business day, it has to be back up and running "somehow". We really aren't the ones who are causing the problem in the first place - we're just a band aid. If later one noone takes the time to rip us off again, you usally got the same problem at hand which caused you having to need us in the first place. And the cycle starts all over again. If all projects were pink roses, fluffy bunnies and butterflies we wouldn't even exist. And contrary to popular belief we usally actually do know how ugly some fixes might be and we do know how to solve things properly if we get the time to understand the architecture beneath. So, please kill the ones who are the real cause of your problem. We duct tape coders or fixers or however you might call us aren’t the cause of the problem – we just apply a certain skill when a problem already happend.

No matter wether one likes us or not – we’re doing this not just randomly out of the blue or the evilness of our hearts to make your life miserable but in cases when we’re asked to “fix things”.

We aren’t the one causing the tight deadlines or the total lack of proper project management. We aren’t the ones who fail to see IN TIME a drowning project and rescue it while there is time.

We also usally warn beforehand that this is going to be ugly if we get unleashed two days before delivery.

It’s also usally not our fault not (yet) having the understanding of the entire system – how could we within two days? We get thrown (just happened to me last month) onto a project 6 days before deadline and we get chosen BECAUSE the deadline is to be kept and someone else failed to keep it for whatever reason.

This is a management decision and not our own. Usally, our understanding is pretty good for the amount of time available – how could we get blamed for NOT having more understanding of the underlying architecture?

If there even is any design or architecture to speak of – half of you obviously assumes always sitting in front of well designed, properly crafted code. Yours might be – the code we see and have to fix, often (usally) isn’t proper or well designed. Otherwise, we wouldn’t get called anyways if everything would be in order.

We’re the idiots who get up at three in the night because some system broke down and before the start of the business day, it has to be back up and running “somehow”.

We really aren’t the ones who are causing the problem in the first place – we’re just a band aid. If later one noone takes the time to rip us off again, you usally got the same problem at hand which caused you having to need us in the first place.

And the cycle starts all over again.

If all projects were pink roses, fluffy bunnies and butterflies we wouldn’t even exist.

And contrary to popular belief we usally actually do know how ugly some fixes might be and we do know how to solve things properly if we get the time to understand the architecture beneath.

So, please kill the ones who are the real cause of your problem.

]]>
By: Johnicholas/2011/03/19/how-not-to-get-things-done/#comment-1784 Johnicholas Sun, 20 Mar 2011 02:02:26 +0000

In brief, one programmer habitually gets things from nothing or not-working to working but ugly and unmaintainable, and another programmer habitually refactors the first’s output into reasonable shape.

Your suggestion of killing the people who Get Things Done is excessive. Not everyone can do what they can do, and you may be able to hire complementary “refactorers” who need something to start from. All-rounders are more capable, but they’re not necessarily available.

Rather, you should stop considering “working” to be equivalent to “done”, and stop leaving timebombs in the code. Don’t blame the fixer, blame the people who say “ugly but working is good enough”.

]]>
By: FieldsOfCarp/2011/03/19/how-not-to-get-things-done/#comment-1782 FieldsOfCarp Sun, 20 Mar 2011 00:51:32 +0000 I'm a huge fan of automated tests for helping address code quality issues, but it's important to realize that the sort of problems Ben describes as being caused by the Fixer are problems tests won't spot for you. The addition of sneaky global state or the breaking of subtle invariants are both things that often won't break automated tests, because the badness is subtle enough that nobody ever thought to encode it in a test. Tests are also bad in general at stopping you from doing 'vaguely bad' things like introducing new global state, because it's very hard to write tests that will catch every permutation of bad programmer behavior. I’m a huge fan of automated tests for helping address code quality issues, but it’s important to realize that the sort of problems Ben describes as being caused by the Fixer are problems tests won’t spot for you. The addition of sneaky global state or the breaking of subtle invariants are both things that often won’t break automated tests, because the badness is subtle enough that nobody ever thought to encode it in a test. Tests are also bad in general at stopping you from doing ‘vaguely bad’ things like introducing new global state, because it’s very hard to write tests that will catch every permutation of bad programmer behavior.

]]>
By: Miles/2011/03/19/how-not-to-get-things-done/#comment-1779 Miles Sat, 19 Mar 2011 22:47:56 +0000 Fixers are valuable team members but if there is not emphasis on testing and code quality any programmer on the team is as likely to cause code rot. Fixers are just the most visible, a lot of this comes down to leadership: it has to be understood that causing a code rot is not acceptable. The rest is education for managers that just because something works does not mean the task is complete... Fixers are valuable team members but if there is not emphasis on testing and code quality any programmer on the team is as likely to cause code rot. Fixers are just the most visible, a lot of this comes down to leadership: it has to be understood that causing a code rot is not acceptable. The rest is education for managers that just because something works does not mean the task is complete…

]]>
By: FieldsOfCarp/2011/03/19/how-not-to-get-things-done/#comment-1772 FieldsOfCarp Sat, 19 Mar 2011 17:54:34 +0000 The dangerous ones are the programmers who I call "straight line programmers". They start at A, and they have a task to get to B, and they take the 'as the crow flies' path. Everything in their way is ignored/bulldozed. Pass a new instance into a constructor? Nah, just add a global. (etc.) Basically, they treat code you need to ship like prototype code and their time as more important as everyone else's... There's a time and a place for that, but some programmers indiscriminately apply it. The dangerous ones are the programmers who I call “straight line programmers”. They start at A, and they have a task to get to B, and they take the ‘as the crow flies’ path. Everything in their way is ignored/bulldozed. Pass a new instance into a constructor? Nah, just add a global. (etc.)

Basically, they treat code you need to ship like prototype code and their time as more important as everyone else’s…

There’s a time and a place for that, but some programmers indiscriminately apply it.

]]>
By: Ben Carter/2011/03/19/how-not-to-get-things-done/#comment-1763 Ben Carter Sat, 19 Mar 2011 14:55:32 +0000 Yeah. I've also seen CrazyFast Fixers turn into CrazyFast Robust & Careful Fixers as time progressed and they gained more experience. And on the other side of approach, people who initially were way too careful & thinking way too much getting faster & more confident (while still being careful enough) as they got more experience. In a lot of cases these traits (Fixer, Architect, Thinker etc.) are not something you have your whole life. People, their experience and their approaches change as time goes by. Yeah. I’ve also seen CrazyFast Fixers turn into CrazyFast Robust & Careful Fixers as time progressed and they gained more experience. And on the other side of approach, people who initially were way too careful & thinking way too much getting faster & more confident (while still being careful enough) as they got more experience.

In a lot of cases these traits (Fixer, Architect, Thinker etc.) are not something you have your whole life. People, their experience and their approaches change as time goes by.

]]>
By: Dylan Cuthbert/2011/03/19/how-not-to-get-things-done/#comment-1757 Dylan Cuthbert Sat, 19 Mar 2011 12:45:12 +0000 IMO you need a good mix of people on your team. You need Fixers, you need Doers, and you need Thinkers and whatever permutations thereof. But you can't just have one of those because then you'll either end up with Canabalt, or a heap of beautiful but unshippable infrastructure. IMO you need a good mix of people on your team. You need Fixers, you need Doers, and you need Thinkers and whatever permutations thereof. But you can’t just have one of those because then you’ll either end up with Canabalt, or a heap of beautiful but unshippable infrastructure.

]]>
By: snake5/2011/03/19/how-not-to-get-things-done/#comment-1754 snake5 Sat, 19 Mar 2011 11:31:56 +0000 Writing the code in the first place is only a small part of the task, you then have to test it until it breaks, then fix it, then test it again and iterate until you reach a point where you cannot break it anymore. Then, and only then, the task is done on my list. Very often, a seemingly insignificant issue might be the tip of the iceberg and there is something seriously flawed looming right under. Delaying fixing it because it is not part of the task is tempting, but that's a bad idea. My main concern about "getting it done" quickly is that it usually means testing got neglected. I want to be confident about the code, and that means it has been properly tested and contains meaningful asserts in case something peripheral would go wrong. This has nothing to do with over-engineering, quite far from it actually, the simpler the code is the easier it is to test all its execution paths. Writing the code in the first place is only a small part of the task, you then have to test it until it breaks, then fix it, then test it again and iterate until you reach a point where you cannot break it anymore. Then, and only then, the task is done on my list. Very often, a seemingly insignificant issue might be the tip of the iceberg and there is something seriously flawed looming right under. Delaying fixing it because it is not part of the task is tempting, but that’s a bad idea.

My main concern about “getting it done” quickly is that it usually means testing got neglected. I want to be confident about the code, and that means it has been properly tested and contains meaningful asserts in case something peripheral would go wrong.

This has nothing to do with over-engineering, quite far from it actually, the simpler the code is the easier it is to test all its execution paths.

]]>
By: . .. . . ./2011/03/19/how-not-to-get-things-done/#comment-1746 . .. . . . Sat, 19 Mar 2011 07:15:10 +0000 Of course you're using more man hours - a better quality solution is going to cost more than the Fixer's original solution. That's the point of pairing him with another programmer (ideally someone who knows those systems better, but anyone would do, really). Saying it's not possible is entirely missing the point. Of course it's possible. Of course you’re using more man hours – a better quality solution is going to cost more than the Fixer’s original solution. That’s the point of pairing him with another programmer (ideally someone who knows those systems better, but anyone would do, really). Saying it’s not possible is entirely missing the point. Of course it’s possible.

]]>
By: Craig/2011/03/19/how-not-to-get-things-done/#comment-1744 Craig Sat, 19 Mar 2011 05:03:45 +0000 I'm going to play devil's advocate here and say that the Fixer is awesome, and the problem here is a complete failure of management. The Fixer has a demonstrated ability to understand systems and to address problems. These are both highly valuable traits. You describe how a skilled fixer will dive in and surgically address a problem (of course, with complete disregard for the long-term impact on the project), and that this can cause pain down the road. I think you'll agree that those long-term consequences can apply to any change made by any programmer; not just a Fixer. You've described how a Fixer can become management's hero because they get things done, and because some code quality issues are considered 'acceptable'. This is the root problem: Code quality issues (or 'technical debt') are basically trading some short term gains for the knowledge that you're going to cost yourself more work down the line in the project. Sometimes this is the correct trade to make (like if it lets you hit a ship date that's a week away), and in those cases, you shouldn't be afraid to make that trade. Most of the time, though, it's not the right trade. The important thing is to make that decision as a team instead of letting it happen by accident when the Fixer sits down to work. When something goes horribly wrong and the Fixer is needed, you should figure out how it happened and *fix that*, and you should agree as a team that it's time to accrue some debt to hit your deadline (or perhaps decide that a higher-quality fix is in order). Care about code quality? Good! Do something about it: Get management on your side. Convince them it actually fucking matters. If they won't listen, either your managers suck, or you're not communicating with them effectively - do something about that. If management is behind you on code quality, the Fixer will have two options: Produce quality code, or leave. It's quite possible for a programmer like him to write good code if you put the right incentives in place and put him in an environment that makes it possible. Keep running into horrible road blocks before a deadline that only the Fixer's heroic code mangling can save you from? Maybe the root problem there is bad scheduling and bad planning? Fix that instead of getting rid of the Fixer. You're going to want him around when things inevitably go wrong, but perhaps if you run your project correctly that'll be 'once or twice per project' instead of 2 times a week. In particular, I'd argue that the Fixer is tremendously valuable because <b>if you pair him with another programmer, the two of them can work together to solve problems as fast as the Fixer would (if not faster), while still producing quality code.</b> I’m going to play devil’s advocate here and say that the Fixer is awesome, and the problem here is a complete failure of management.

The Fixer has a demonstrated ability to understand systems and to address problems. These are both highly valuable traits. You describe how a skilled fixer will dive in and surgically address a problem (of course, with complete disregard for the long-term impact on the project), and that this can cause pain down the road. I think you’ll agree that those long-term consequences can apply to any change made by any programmer; not just a Fixer.

You’ve described how a Fixer can become management’s hero because they get things done, and because some code quality issues are considered ‘acceptable’. This is the root problem:

Code quality issues (or ‘technical debt’) are basically trading some short term gains for the knowledge that you’re going to cost yourself more work down the line in the project. Sometimes this is the correct trade to make (like if it lets you hit a ship date that’s a week away), and in those cases, you shouldn’t be afraid to make that trade. Most of the time, though, it’s not the right trade. The important thing is to make that decision as a team instead of letting it happen by accident when the Fixer sits down to work. When something goes horribly wrong and the Fixer is needed, you should figure out how it happened and *fix that*, and you should agree as a team that it’s time to accrue some debt to hit your deadline (or perhaps decide that a higher-quality fix is in order).

Care about code quality? Good! Do something about it: Get management on your side. Convince them it actually fucking matters. If they won’t listen, either your managers suck, or you’re not communicating with them effectively – do something about that. If management is behind you on code quality, the Fixer will have two options: Produce quality code, or leave. It’s quite possible for a programmer like him to write good code if you put the right incentives in place and put him in an environment that makes it possible.

Keep running into horrible road blocks before a deadline that only the Fixer’s heroic code mangling can save you from? Maybe the root problem there is bad scheduling and bad planning? Fix that instead of getting rid of the Fixer. You’re going to want him around when things inevitably go wrong, but perhaps if you run your project correctly that’ll be ‘once or twice per project’ instead of 2 times a week.

In particular, I’d argue that the Fixer is tremendously valuable because if you pair him with another programmer, the two of them can work together to solve problems as fast as the Fixer would (if not faster), while still producing quality code.

]]>
By: Paul-Laska/2011/03/19/how-not-to-get-things-done/#comment-1740 Paul-Laska Sat, 19 Mar 2011 01:31:01 +0000 Relevant: Hey! You need us hacky people too. Or else the pristine programmers would enter an infinite-refactoring loop. Hey! You need us hacky people too. Or else the pristine programmers would enter an infinite-refactoring loop.

]]>