The last couple of years more and more people have been moving towards Agile development. These techniques aren’t new, most we’re devised in the 80s or 90s. But finally these days programmers and (more importantly) business consultants, architects and clients have learned to love and embrace Agile development.
Evolving requirements
It has now become common knowledge that you can’t write down all the requirements before you start the project. These requirements have to be written down in an evolutionary matter. In short cycles/sprints we build pieces of the program and also iteratively extract the latest requirements from our clients. This is all based on the principle of evolution. Like everything in life, you get the best with incremental steps towards improvement.
Evolving code!
But why stop there? Today most programmers have developed a mindset in which requirements have to be extracted evolutionary. But they seem to forget their own work!? They still think their frameworks and their architecture has to be solid at the start of their project. Also, once code is written, it is done.. right?
Wrong. In my experience all great code is written at least twice. The first time you are too busy interpreting the requirements and figuring out what it should do. Sure, when you see certain patterns, we know that we need to extract methods and shift responsibilities around. The code you’ll end up can be pretty good, but it isn’t great.
In our current project, almost all important features have been rewritten from scratch multiple times. And slowly but surely the code is becoming better and better. Once you’ve made the 3rd or 4th addition to a certain piece of code, or you’ve fixed another bug, you’ll know where the code smells. You’ll feel like avoiding that piece of code, and you are glad when you are done fiddling with it. What do I do when I get this feeling? I delete the code.
But… but… then you have to start all over again!?
Wrong again! Sure, there is nothing left in the IDE, the code is gone, maybe some tests survived. You do have a solid understanding what the code should do. You also know what the code looked like before, so you know where it hurt/smelled in the past! With this knowledge you’ll write much better, maybe even great code! Sure, we could have kept the code and played with it some more, refactoring methods and responsibility… but there is nothing like grabbing the opportunity to start over again, and do it better.
Again, like all things in life: To make something great, it has to go through multiple evolutionary iterations. This is true for your requirements, your architecture and also your code.
Doing it twice, twice as slow?
When I tell people that in my opinion all code needs to be written at least twice, they are afraid the project will take double the time. But this is far from true. Here is why:
- The second time you write the code, it’ll only take a fraction of the time it took initially.
- After rewriting the quality of the code is significantly higher, improving maintainability, extendability and also programming velocity.
Good luck, keep rewriting and evolve your code! And if you think rewriting doesn’t work… we have proof!
Not all code should be rewritten though. If it’s good (enough) keep it running.
But if it hits/creates bottlenecks or covers core business (rules) a rewrite is a good way to go.
But you may want to keep the comments ;)
I keep telling people the exact same thing, but somehow the message doesn’t get trough. I also find twice a rather low number, I tend to think of good code not before the 7nth or so rewrite.
There are problems though with rewriting the same project several time:
-when the projet become big, huge, rewriting it take years. More than that i will be rewriten by some new people too, including beginners. Chances are the rewrite of a big enough project will not increase its quality because the new team didn’t learn from the old one. And because this is so long, this is not feasible. Other will go to the next step, make money with that, while you just keep at the same place, maybe with a slighly better code, but no new features. You can and you will need to rewrite it part by part, but this mean that some point (like overall architecture) might never change even if flowed. Think about it. We all know the web is broken as an application platform, but we all develop for it and keep HTTP/HTML/CSS/JS stack anyway.
- Like you say, it is iterative. In fact you can continue to improve, and you could rewrite your project every year, and each year you would improve. Well not even, you might experiment in the wrong direction, and new version might be worse than the old one. But anyway you can’t rewrite every year, every month or even every 2 years.
But did you ever wonder why companies look for programmers with X years of experience, in particular in the same field (business domain, technology stack, programming language…)? That exactly that. When you have lot of experience, you wrote lot of code. You corrected lot of bug. Hopefully, you get a real sence of things, and if you write something, it will be somewhat better than you, a few ago. And than beginers.
Also not all people are equals on this. We all know some programmers are really good, and they don’t have to wait year to be good. Other stay at the average all their life. Hopefully they go for another carrier (like management) where they can be more effective.
That mean that the secret weapon might not be to rewrite you software several time but maybe to hire people that already know how to make the software. You have to pay more for them, but the result will be far far better.
Don’t rewrite the complete project, just take one part at a time (the worst parts) and rewrite those! If you keep refactoring and rewriting existing code it’ll become much easier to add new functionality to it.
http://www.1729.com/blog/EconomicsOfTestingUglyCode.html
I agree. This confirms what I’ve learned over the years and also the recent HTTP library project. The first time I wrote it, well it was for WordPress and it sucked, but worked well. It was meant to suck. The second, I tried to do it right and failed. This third time, well, it is far better.
[...] the feature again, but applying all the lessons we had learned from the first attempt. A recent blog post by royvanrijn on this very topic made me appreciate what we had done. He points out that the best code occurs [...]
[...] Great code is written twice (or more) [...]
[...] Great code is written twice (or more) [...]
[...] 导读：本文是从《Great code is written twice (or more)》这篇文章翻译而来。 [...]
[...] 收藏夹 谷歌书签 QQ书签 新浪微博 百度搜藏 腾讯微博 白社会 开心网 人人网 豆瓣 搜狐微博 Delicious function doZoom(size) { var zoom = document.all ? document.all['entry'] : document.getElementById('entry'); zoom.style.fontSize = size + 'px'; } 现在的位置: 首页 ＞IT外刊＞正文 RSS 小 中 大 上篇 好程序需要你写(至少)两遍 发表于1 分钟前 ⁄ IT外刊 ⁄ 暂无评论 ⁄ 被围观 1 views+ 分享到： 新浪微博 QQ空间 开心网 人人网 本文是从 Great code is written twice (or more) 这篇文章翻译而来。 [...]
[...] 导读：本文是从《Great code is written twice (or more)》这篇文章翻译而来。 [...]
[...] 英文出自：redcode 你可以发表评论、引用到你的网站或博客，或通过RSS 2.0订阅这个日志的所有评论。 上一篇：盘点云计算领域最重要的10家公司 没有评论▼ 我来说两句 [...]