5 ms·

The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't neces

The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.

peri 12y ago
I think that confusing "duct tape", "gaffer tape", and "crazy glue" is a problem in any kind of shop. Maintainable glue code is more like painter's tape or gaffer tape than it is rubber cement, imo.
sgift 12y ago
> you're gonna wish you spent a bit more time at the starting line wondering what to build it out of. Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually all the "yeah, we should have thought about that before" remarks are just that. You wouldn't have thought about it before, because you need the scars to tell you "Bad idea, don't do it again."
- waps 12y ago
  As a general rule, decision made due to regret ... well tend to lead to more regret. That happens to me a lot. What a lot of people don't do after a project is to first evaluate how well the whole thing worked. How many bug incidents were there ? How many times did a design decision have to be refactored out ? How many times did you really have a problem ? Then, first things first, take out all problems that were obviously not project related. The team moved ? Someone went on holiday ? All of those don't matter. After that, you'll have problems left. If it's 3 problems, none of which delayed more than 2 weeks/10%, your project went as well as you can reasonably expect. Don't change a thing. If after that you arrive at the conclusion that the project went ~80% as planned, then you've simply done it right. There are no lessons to be drawn from mistakes, because the fixes are likely to screw you up more than the "mistakes". Even when this is not the case, you should limit fixes. Take the top-3 problems, at the very most, and implement a fix for one of them. Then try to mitigate the second and stay away from everything else. If you don't you'll have seriously more regrets about your next project a whole than your current project. Lots of people generally don't do this. They do a project, then switch programming languages. That's a decision you should make once in 5 years (unless you're switching back after a disappointment). People seriously overcompensate. From management to developers. Redesigning an entire organisation because one bad apple leaked something is very likely not justified, and similarly a rewrite is almost never justified.
bermanoid 12y ago
Since I moved into a lead role (where I still do day to day coding but don't do as much as my reports), a good rule of thumb for me has been that if I can't track down the offending line of code within half an hour based on a stack trace coming in from a significant portion of end users, someone has overarchitected something. Figuring out when something is too simple is trickier, but it tends to be pretty obvious because a ton of bugs come in that are easy to locate. Over the past few years, I've decided that as a general rule I prefer engineers that under-architect to those that take it too far, because the damage is far easier to mitigate...
rtpg 12y ago
a hundred times this. Technical debt is painful on all levels. It makes things falling apart more likely, it makes refactoring more painful, and it adds cognitive load. The argument that you can absorb technical debt only really works if you plan on an aquihire to save yourself, because if not it's very likely you'll have to clean it up (and you'll have paid a decent amount of interest on it). It's not like good code and code that's easy to write are two ends of a line.
mercer 12y ago
Seems like a good context to recommend the wonderful 'Simple Made Easy' talk by Rich Hickey, the creator of Clojure. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

peri 12y ago

I think that confusing "duct tape", "gaffer tape", and "crazy glue" is a problem in any kind of shop. Maintainable glue code is more like painter's tape or gaffer tape than it is rubber cement, imo.

sgift 12y ago

> you're gonna wish you spent a bit more time at the starting line wondering what to build it out of. Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually all the "yeah, we should have thought about that before" remarks are just that. You wouldn't have thought about it before, because you need the scars to tell you "Bad idea, don't do it again."

waps 12y ago
As a general rule, decision made due to regret ... well tend to lead to more regret. That happens to me a lot. What a lot of people don't do after a project is to first evaluate how well the whole thing worked. How many bug incidents were there ? How many times did a design decision have to be refactored out ? How many times did you really have a problem ? Then, first things first, take out all problems that were obviously not project related. The team moved ? Someone went on holiday ? All of those don't matter. After that, you'll have problems left. If it's 3 problems, none of which delayed more than 2 weeks/10%, your project went as well as you can reasonably expect. Don't change a thing. If after that you arrive at the conclusion that the project went ~80% as planned, then you've simply done it right. There are no lessons to be drawn from mistakes, because the fixes are likely to screw you up more than the "mistakes". Even when this is not the case, you should limit fixes. Take the top-3 problems, at the very most, and implement a fix for one of them. Then try to mitigate the second and stay away from everything else. If you don't you'll have seriously more regrets about your next project a whole than your current project. Lots of people generally don't do this. They do a project, then switch programming languages. That's a decision you should make once in 5 years (unless you're switching back after a disappointment). People seriously overcompensate. From management to developers. Redesigning an entire organisation because one bad apple leaked something is very likely not justified, and similarly a rewrite is almost never justified.

bermanoid 12y ago

Since I moved into a lead role (where I still do day to day coding but don't do as much as my reports), a good rule of thumb for me has been that if I can't track down the offending line of code within half an hour based on a stack trace coming in from a significant portion of end users, someone has overarchitected something. Figuring out when something is too simple is trickier, but it tends to be pretty obvious because a ton of bugs come in that are easy to locate. Over the past few years, I've decided that as a general rule I prefer engineers that under-architect to those that take it too far, because the damage is far easier to mitigate...

rtpg 12y ago

a hundred times this. Technical debt is painful on all levels. It makes things falling apart more likely, it makes refactoring more painful, and it adds cognitive load. The argument that you can absorb technical debt only really works if you plan on an aquihire to save yourself, because if not it's very likely you'll have to clean it up (and you'll have paid a decent amount of interest on it). It's not like good code and code that's easy to write are two ends of a line.

mercer 12y ago

Seems like a good context to recommend the wonderful 'Simple Made Easy' talk by Rich Hickey, the creator of Clojure. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy