Time to Do Software Right

I've been thinking about two recent posts by Jeff Atwood. In UI is Hard, Jeff cites evidence that UI programming is harder than server-side programming. His recommendation is to think about the UI first.

In my opinion, both the premise and the solution are wrong (or at least they aren't universally correct). UI programming is certainly hard. The UI should never be an afterthought, but server-side programming can be equally hard to get right. You must design for scalability, performance and reliability on the server-side. If you don't, even the most elegant front-end will be broken from the user's perspective.

So it shouldn't be "UI first". Instead it should be "UI and server-side together". And you might need a few iterations to get it right. The problem is iterations take time.

In The Broken Window Theory, Jeff argues we should take the time to fix "broken windows" (bad designs, wrong decisions, poor code). Failure to do so breeds an atmosphere of sloppiness. When a developer see problems throughout the code, he wonders why he should spend the time to do his part right.

I agree with 100% with this analysis, but let's consider the cause of the "broken windows". Is it incompetence or laziness on the part of developers? Sometimes, but more often I think it is lack of time. Compressed schedules are epidemic in the software industry. Because of the schedule, we short-change the design phase of projects, we ignore the need to iterate in the design-development process, and pretend not to see the myriad "broken windows" in our code. After all, we can fix the process and the code "next release".

In The Mythical Man-Month, Dr. Fred Brooks likens good software to good cooking. Brooks quotes the resolute Chef Antoine:

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.

If we had more Chef Antoines in the software industry, we might have happier customers.