I’ve been writing software for over a decade now and I think I’ve established a minimal, yet very effective, set of rules for writing software:
Amit’s rules for writing software
- Make the users happy.
- Allow for known future modifications.
Doesn’t seem like much, does it? But, much like code, the brevity of these rules says nothing about what they encapsulate.
The first rule requires you to make the users happy. And by “happy” I mean make the users think your software is worth the time, money and effort they invested in order to use it. Some things are hidden in this rule – shipping on time, for example, is something that makes users happy. But sometimes achieving this goal requires you to make compromises and write code that isn’t according to your standards. Maybe you had to make an ugly shortcut, duplicate code, a hack, whatever. As long as the users are happy it’s OK to cut corners but…
The second rule says you should allow for known future modifications. That’s where all of your education, experience and religious pursuit of perfect code come into play. To make software future-proof you have to write good software, which practically disallows the aforementioned hacks from rule #1.
A delicate balance exists between the rules. Making users happy will presumably allow for a great first version but you might end up with unmaintainable software. On the other hand, write code without compromise and you may never ship. If you manage to write non-compromising software that your users are happy with, kudos to you.
I never could.
From my limited experience:
Given enough time and momentum, many of the open-source software packages tend to gravitate towards compliance with these two rules, with the (sometimes painfully obvious) exception of “shipping on time”.
Commercial software rarely fully complies with any of these rules. Early versions rarely make the users very happy, and older versions, while succeeding in making the user happy most of the time, rarely have any significant amount of “clean code” in them.
So you are not alone, and you probably would be if you could do this…
The thing is that it took me time to get to these rules. I used to be a “perfect design” zealot and had a hard time compromising on code. But now you can pass by me almost anything as long as it works well and doesn’t interfere with known (!) future enhancements. In the past hearing someone say something like I just did would probably make me hate him :)