I'm in an odd position on this one, because I agree with his list of desirable practices at the end, and disagree emphatically with his idea that writing something, anything, beats thinking about writing something 100% of the time. Much of the "quick" code we write in the real world ends up enshrined the minute it works, and never gets revisited or cleaned up. I once had to deal with a piece of data import code written by a predecessor who had moved on to management. He had a single 500-line try-catch block in which everything happened. When I mentioned that this wasn't the most maintainable or comprehensible approach, he simply replied that "it works." That statement, "it works", is a pretty low bar in software, imo.
I have my own codebase at work, for the in house database. Some of the time it gets written well, other times things are rushed and done to a poor standard.
I often re-factor, but there are some bits of code, which are a mess to look at - but they work. I look at the possibility of re-factoring, but why bother when, a) it works, has been for months b) the code doesn't change and is not likely to in the future. Aesthetically it could be a lot better. But it isn't really getting in the road, until it affects something else.
Agree somewhat. This is also quite common. I think what new person forgets (I'm guilty) when looking at "rubbish" code is the context in which it was written. Was this done at 3am the night before it shipped? Was team morale incredibly low and this was the only guy left to write this? Did he/she not know of a better way? Did this start as a simple block and slowly accreted over time? Was he/she going through a rough patch but didn't have the time to refactor it. We've all had off days and spent more than another day unpicking what we did. Heck I look at code I wrote 12 months ago and could quite often tear it apart. This kind of thing just happens in places. Discipline is key. It's hard, but sometimes there has to be a balance or things wouldn't get done.
I have to agree with that Mark. However there is (or a least should be) a difference between writing something and committing something. It can be hard to hold a manager off when you've got "functional code that's still a bit rubbish" but getting to that stage first before going over the top can (in my experience) massively accelerate development
Agreed. The question is whether, in those cases where you begin with a "rough version," you are afforded the time for refinement? Most clients don't understand code, much less the difference between good code and bad. And very few of them are equipped to evaluate the long term costs of maintaining bad code. Hell, very few of _us_ are equipped to do that. So I remain very wary of this concept that time spent thinking is time that could have been better spent at the keyboard. Too often you only get one shot.
