Blog Tag advice

Top Ten of Programming Advice NOT to Follow

Published by Myles Braithwaite 3 years, 2 months ago. 0 Comments

Tags , and

“Desgin first, then code”

1) “Design first, then code”

Okay, things are going political now, but even though you will find many many people who disagree, I still feel that this is the single most valuable lesson that I have learned. Designing first and then coding simply doesn’t work. The problem is that this is so counter intuitive that you more or less have to find it out for yourself.
I think every programmer has experienced a project with no planning turning into a mess. Changing such code can only be done with hacks and patches to everyones great frustration. It is at that time that you realize that the only decent way to code is by designing things right from the start. Only now the frustration is even greater when you realize that your beautiful design isn’t prepared for exactly this new feature that you are to implement now. What to do then?
You should think before you code. Go ahead, but think for hours, not days. Don’t kid yourself into believing you can sketch an entire design document with UML diagrams and everything without making mistakes. At least, don’t think you can do so any faster than you could have simply written the code.
Now, if you’re not familiar with agile methodologies such as eXtreme Programming, the whole concept of evolving design sounds like the very problem programmers are trying to solve with all their clever ways of abstracting things out. And indeed, evolving design only works well if you follow a number of practices. Short iterations, automated testing and frequent refactoring being the most important.
I suggest you read Martin Fowler’s excellent article Is Design Dead? which explains it all a lot better that I am capable of.

Top Ten of Programming Advice NOT to follow by Kristian Dupont Knudsen. | Top Ten of Programming Advice NOT to follow