I agree that high quality software is usually more cost effective than lousily-put-together software, but not in all cases. If you are building something new,

I agree that high quality software is usually more cost effective than lousily-put-together software, but not in all cases. If you are building something new, as the article recognises, or in some cases you don't have a lot of experience, or you expect to grow fast, etc., what you build will have problems anyway, it might soon become obsolete, unmaintainable or ineffective... and then die. You should still have a decent plan, but in these cases it would be more effective to not bother much about high quality. You need to be really prepared in order to write high quality software in a business environment, and that's not something achievable through just will, in a reasonable amount of time. You need to understand sometimes you lack experience / definite direction / resources / ... If you have the experience, a clear scope and goals, then high quality might indeed be the most effective way to go. When building your own, small projects, high quality might be the way to go too, as you won't hate what you are doing and you will learn much more. Here effective would mean a very different thing. But I think that considering the effectivity of code in different contexts is a better perspective than talking about quality. It's always a good idea to spend some time considering the architecture; it's always a good idea to keep things modular; to keep code as easy to delete/replace as possible; to write as little code as needed. But the quality? Well, it depends. What's even quality? (and I'm the kind of guy that can't stand writing lousy or ugly code :D)