The Case for Slow Programming
I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win.<p>Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true.<p>What we're really saying is our industry is short on <i>skill sets</i>. With specific skill sets, you can build architecturally sound systems at no extra cost.<p>If I were to build a house today it would take me much longer than someone else because I don't have the necessary skills. I might hurry in which case the house would be shoddy. Is the shoddiness of the house <i>necessarily</i> because I hurried? No. It's because I didn't acquire the required skill sets first.<p>The software industry has no such (practical) concept of the skill sets required to build architecturally sound systems. We have a bunch of well-meaning hackers, and as a result shoddy systems that decay into technical liabilities.<p>Our industry needs to solve this skill set problem. The challenge is that academia has a hard time teaching these skill sets, because they are so removed from the practitioner. And businesses can't teach it b/c it takes years and special experience to actually teach it. So it's not advantageous to a business to teach those skill sets.<p>So how do we do it? And how do we organize an industry around <i>professionals</i> who know how to build architecturally sound systems and code? This is a very difficult problem for a world that has such high demand for code and such little understanding of what the professional skill set would afford them.