Comments on: practice makes perfect – a ramble with bad capitalisation A fantastic article! I 100% agree. I always find that when I come to write something new, or have to try and solve a problem I have not encountered before, it is all too easy to get caught up thinking of the myriad of different ways of approaching the situation. This seems to always end in going round in circles not knowing which path to take, and as a result nothing ends up getting done. The best approach I find is to start writing code, and to get something down on paper as it were. When you do, you find that 'spidey' sense you mentioned will point you in the right direction and stop you doing anything too daft. When you have something concrete, it then helps to get some distance from what you have just written (a good nights sleep is invaluable in the programmers arsenal) and then you can go back and re-factor or re-write the system knowing a great deal more about the problem and how to solve it than you did before. In the process you will cause a bit of a stink, but the cleanup after will make the fresh smell all the sweeter :) A fantastic article! I 100% agree.

I always find that when I come to write something new, or have to try and solve a problem I have not encountered before, it is all too easy to get caught up thinking of the myriad of different ways of approaching the situation.

This seems to always end in going round in circles not knowing which path to take, and as a result nothing ends up getting done.

The best approach I find is to start writing code, and to get something down on paper as it were. When you do, you find that ‘spidey’ sense you mentioned will point you in the right direction and stop you doing anything too daft. When you have something concrete, it then helps to get some distance from what you have just written (a good nights sleep is invaluable in the programmers arsenal) and then you can go back and re-factor or re-write the system knowing a great deal more about the problem and how to solve it than you did before.

In the process you will cause a bit of a stink, but the cleanup after will make the fresh smell all the sweeter :)

]]>
By: Patapom/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-1342 Patapom Tue, 08 Mar 2011 23:08:05 +0000 @Reg I couldn't agree with Joel's article less. The reason that 2 page function needs rewriting is because all those "bug fixes" are made by people that no longer work here and are undocumented. Every attempt to maintain the software takes twice as long and causes obscure difficult to fix bugs because no-one left truly understands the philosophy of the code or why the bugs were fixed that way. Also the fact that the code needed so many obscure bug fixes has highlighted the inherent flaws in the original design that can now be fixed with better structuring.The real issue Joel is highlighting is that if you have a multi-million dollar piece of software that took many man-years of work to build, don't underestimate how long it will take to build it again from scratch with a fresh team who have probably never built anything like that before. This is not the same situation most people are in when they are looking at rewriting an isolated module to make it more readable and maintainable and address some design flaw issues that have exposed themselves through usage. Also don't underestimate the importance of taking ownership of the codebase - often if its someone elses codebase that you are maintaining you will often just here "yeah, it was like that when I started. I'll have a look if there is a fix". @Reg I couldn’t agree with Joel’s article less. The reason that 2 page function needs rewriting is because all those “bug fixes” are made by people that no longer work here and are undocumented. Every attempt to maintain the software takes twice as long and causes obscure difficult to fix bugs because no-one left truly understands the philosophy of the code or why the bugs were fixed that way. Also the fact that the code needed so many obscure bug fixes has highlighted the inherent flaws in the original design that can now be fixed with better structuring.The real issue Joel is highlighting is that if you have a multi-million dollar piece of software that took many man-years of work to build, don’t underestimate how long it will take to build it again from scratch with a fresh team who have probably never built anything like that before. This is not the same situation most people are in when they are looking at rewriting an isolated module to make it more readable and maintainable and address some design flaw issues that have exposed themselves through usage. Also don’t underestimate the importance of taking ownership of the codebase – often if its someone elses codebase that you are maintaining you will often just here “yeah, it was like that when I started. I’ll have a look if there is a fix”.

]]>
By: Reg/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-406 Reg Tue, 08 Feb 2011 10:27:14 +0000 .

]]>
By: Fabrice Lété/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-405 Fabrice Lété Mon, 07 Feb 2011 12:47:26 +0000 @James I've seen too much cargo cult programming to assume programmers consider options if not told to consider them :) Many will, but many just want to "get the job done".But yes, the "never rewrite" pressure is there. Ultimately, it takes programmers who are able to communicate the benefits of that big rewrite to management, and programmers who care about keeping the code in a good state. (It's like the boy scouts - leave the camp ground cleaner than you found it :)It *seems* to me that non-MS Project-driven approaches work better for that. If you regularly take a pulse of how much gets done, it's easier to point out that the existing code base is an anchor on the teams productivity. (As opposed to just keep track how much behind schedule you are now...)Culture is another part - if the company as a whole only values "time to first demo implementation", you're in trouble. As you are when it only looks for the sparkly architecture. They're two sides of the same coin - focusing only on big visible things when judging results. And I miss the voices pointing out that "big architecture" vs. "quick & dirty" vs. "perpetual rewrite" all only say the same thing - a focus on snapshots in time over a consistent view towards code quality. @James I’ve seen too much cargo cult programming to assume programmers consider options if not told to consider them :) Many will, but many just want to “get the job done”.But yes, the “never rewrite” pressure is there. Ultimately, it takes programmers who are able to communicate the benefits of that big rewrite to management, and programmers who care about keeping the code in a good state. (It’s like the boy scouts – leave the camp ground cleaner than you found it :)It *seems* to me that non-MS Project-driven approaches work better for that. If you regularly take a pulse of how much gets done, it’s easier to point out that the existing code base is an anchor on the teams productivity. (As opposed to just keep track how much behind schedule you are now…)Culture is another part – if the company as a whole only values “time to first demo implementation”, you’re in trouble. As you are when it only looks for the sparkly architecture. They’re two sides of the same coin – focusing only on big visible things when judging results. And I miss the voices pointing out that “big architecture” vs. “quick & dirty” vs. “perpetual rewrite” all only say the same thing – a focus on snapshots in time over a consistent view towards code quality.

]]>
By: James Podesta/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-403 James Podesta Mon, 07 Feb 2011 01:34:07 +0000 That's what I'm saying - when you make a choice, be aware what the consequences are either way. That’s what I’m saying – when you make a choice, be aware what the consequences are either way.

]]>
By: James Podesta/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-401 James Podesta Mon, 07 Feb 2011 00:02:33 +0000 Sure, if nobody relies on your code, go rewrite occasionally. It's starting to get a bit harder if you have three teams relying on it. (And of course they are abusing every side effect in the book - since many teams only care about user-observable effects, they're happy to exploit side effects. Which means any refactoring needs to either preserve them, or face the wrath of everybody using it.)Also, let's ignore the point that we need to ship at some point. Boy, rewriting that physics engines three days before code lock sounds *awesome*.Snark aside, like in many of those rants, the most important point is missing - code is engineering, and engineering is about trade-offs. Yes, cleaning up your code is good, and has value - but triggering a whole new QA cycle before you can go to beta costs quite a bit, too. Re-inventing that sweet wheel over there is sure satisfying, and it might even fit your purposes slightly better - but using a ready-made wheel cuts development and maintenance cost.No, I'm not saying over-design and buy everything off the shelf. I'm saying that it's crucial to be *aware* what your choices mean to the project. (But even if you have to use a sub-optimal design, please do write clean code. *That* really shouldn't be that hard) Sure, if nobody relies on your code, go rewrite occasionally. It’s starting to get a bit harder if you have three teams relying on it. (And of course they are abusing every side effect in the book – since many teams only care about user-observable effects, they’re happy to exploit side effects. Which means any refactoring needs to either preserve them, or face the wrath of everybody using it.)Also, let’s ignore the point that we need to ship at some point. Boy, rewriting that physics engines three days before code lock sounds *awesome*.Snark aside, like in many of those rants, the most important point is missing – code is engineering, and engineering is about trade-offs. Yes, cleaning up your code is good, and has value – but triggering a whole new QA cycle before you can go to beta costs quite a bit, too. Re-inventing that sweet wheel over there is sure satisfying, and it might even fit your purposes slightly better – but using a ready-made wheel cuts development and maintenance cost.No, I’m not saying over-design and buy everything off the shelf. I’m saying that it’s crucial to be *aware* what your choices mean to the project. (But even if you have to use a sub-optimal design, please do write clean code. *That* really shouldn’t be that hard)

]]>
By: bobvodka/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-398 bobvodka Sun, 06 Feb 2011 22:29:43 +0000 I agree completely with points 4 and 5; I recently took a day to rewrite our vehicle rendering code with an eye to removing generalisation and allowing for data flow.. net result; a tight loop which shaved 30% (0.5ms in one scene) off the CPU cost on the PS3. I agree completely with points 4 and 5; I recently took a day to rewrite our vehicle rendering code with an eye to removing generalisation and allowing for data flow.. net result; a tight loop which shaved 30% (0.5ms in one scene) off the CPU cost on the PS3.

]]>
By: James Podesta/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-397 James Podesta Sun, 06 Feb 2011 12:30:15 +0000 Nice post. You seem to have rediscovered this – And here is the exception to your rewrite rule...Not all code is good to rewrite, some of it is attached to other interfaces that you have no control over and contain lots of subtle traps. ( I don't just mean computer interfaces, your brain is also a mess of replicated state machine hell, so beware of simple user interface tweaks. )This code, once working, is battle hardened.The cost to test of this code is astronomical.Do not consider a rewrite of this code as a reasonable use of your time, no matter how much you want to, no matter how much it beckons to you.Avoid the urge and embrace the chaos. And here is the exception to your rewrite rule…Not all code is good to rewrite, some of it is attached to other interfaces that you have no control over and contain lots of subtle traps. ( I don’t just mean computer interfaces, your brain is also a mess of replicated state machine hell, so beware of simple user interface tweaks. )This code, once working, is battle hardened.The cost to test of this code is astronomical.Do not consider a rewrite of this code as a reasonable use of your time, no matter how much you want to, no matter how much it beckons to you.Avoid the urge and embrace the chaos.

]]>
By: Gavin Clifton/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-394 Gavin Clifton Sat, 05 Feb 2011 17:19:24 +0000 Insightful article. I gotta admit I was turned off by the blocks of solid text, but you had me hooked by the first few paragraphs. Insightful article. I gotta admit I was turned off by the blocks of solid text, but you had me hooked by the first few paragraphs.

]]>
By: Dylan Cuthbert/2011/02/05/practice-makes-perfect-a-ramble-with-bad-capitalisation/#comment-392 Dylan Cuthbert Sat, 05 Feb 2011 15:47:47 +0000