This post will introduce a set of rules. Because the post is so goddamn long, I will post them here, so you don't have to jump and explain them in the following text. Most probably, I will replace this text with something better in getting to the point sometime in the next few days, we'll see.
THE 10 RULES OF EVOLUTIONARY SOFTWARE:
- The number is not thy god
- Thou shalt not make any great promiss for the future of your project other than 'It'll work'
- Relaxeth
- Thou shalt honour the old code and improve upon it with care
- Thou shalt not kill old features and capabilities unnecessarily
- Thou shalt know that for some reaon the other biblical commandments do not work and thus will not be included
- These 7 rules shall be known as the 10 rules of evolutionary software. Why? See rule number 1.
Disclaimer: This entry is written in English in order to get the message out as far as possible. I think, this is important to tell people. You don't change a mindset by simply saying so, you need to spread the message. Also, I apologize for not having any pictures, just boring text.Lately, lots of software has been delayed or takes really long:
Firefox 3 (added a lot of semi-cool features, btw) ,
WordPress 2.5 (pointlessly - more on that adjective later on -
skipping 2.4 in the meantime), stepmania 4.0 (unusually for me, no complaints here) just to name those I care about myself and can recall within 10 seconds.
So, who's to blame?
My answer is: Version numbers. Or rather, the mindset they introduce.
Some weeks ago, I made some improvements to a Wordpress plugin named
Sociable, a neat little plugin that creates icons which link to a social bookmark service under each post and page, enabling visitors to bookmark it with one click and also potentially a means of viral marketing (as in
viral, not
marketing called viral for no apparent reason or
would like to become viral).
All I did was adding German bookmarking service Yigg to it, five lines of code. To signify the change, I named it version 2.5.3. However, the next day, I also added Oneview and decided not to change the number The change to me seemed to insignificant to reflect this way. Meanwhile, Joost de Valk, the main programmer of Sociable has released 2.5.4, btw.
But this insignificance I felt is a problem many coders and programmers seem to face: The numbers introduce the notion that, if you change something, you better change alot, because you need to justify the new number.
Thus, features become amassed in any new version of a software. Especially Wordpress 2.5 and Firefox 3.0 will diverge from the original software a large amount. Many users will have to completely relearn how to use these programs.
Thing is: There would be no need for this if software development was an evolutionary process, rather than revolutionary.
By revolutionary I mean: Add, change or delete one feature at a time, implement is, change the code so that it works fine. Changes should be subtle and come one at a time, increase the quality of a software without making it something vastly different from former iterations.
Also, abandon words such as "iteration", "version" (when related to time), "revision", "makeover". They all imply segmented time when in reality, time is flowing and thus not segmentable by numbers.
However, abandoning these words also means abandoning the concepts behind it.
"But", millions of programmer voices will shout in terror, "how do we distinguish all those versions of a software without version umbers?".
The answer is simple, really: Dates.
Not the kind you have with a nice woman (although that might help to forget about the problem for a while), but the ones in the calendar. Whenever you implemented a new feature and it is running smoothly, release and instead of a version number add a date, like this:
Wordpress
built (or build) 20-02-07 (or 03-20-07 for Americans)
change(s): implemented automatic feng shui sidebars (now that would be an awesome feature)
stable: yes
files changed: wp-admin/feng-shui-admin.php
That is: Name of the software
date this was last updated
list of changes
Only one point is new to most software and important to my concept:
date of last updateThis replaces "version number". Operating with dates makes it harder to set them as a goal and also they do not imply anything about the hange itself so there is no psychological pressure to change just about everything in a software. Rather, it gives you freedom to just change something incredibly small, that only needs one line in one file changed.
The update never claimed to do something huge. If it does change something major, say so in the changelog.
afterwordsGranted, some changes are huge-scale and might require developers to change the whole package.
My sites usually go through an evolutionary change, I never changed one radically from one day to another.
There was one exception, though: When I decided to make one of my sites two-column instead of three-column, I had to relocate everything that used to be in the right-hand sidebar (that was deleted) to some other place on the pages. I ended up changing almost every file in my theme (custom WP theme).
Those things happen. But you should just not aim for them.
Do, what it takes to improve a software. But do not force news.
Or, as the seemingly forgotten saying goes: Never change a running system.
PS 2.4Right, the part of skipping Wordpress 2.4 being pointless: Ask yourself just one question - what for?
What is the difference between publishing 2.4 later or naming it 2.5 that makes the latter preferable? is it that important to keep up with a roadmap that does nothing but list numbers, anyways? I mean, if it listed features to be implemented, alright. But numbers?
The German language has a beautiful explanation for this:
Schwanzvergleich - dick compare.
It means, two people compare something and whoever has the bigger one (version number, number of sales, military rank, academic degree, dick) wins. I really dn't see any other point in aiming for a number.
Aim for a good software that runs. And stop thinking of it being imperfect the very day you release it. of course, it is imperfect. Nothing is perfect.
Just relax, see it running and if there is something to change, do so. If you got a good idea, implement it. With care and taking time.
It's not like anyone pays you to rush a sh*tload of features in, anyways.
BOILING IT DOWN: 10 RULESTo boil down my text, I'd like to introduce a set of 10 rules that I deem considerworthy, and also pathetically biblical in reference:
THE 10 RULES OF EVOLUTIONARY SOFTWARE:
- The number is not thy god
- Thou shalt not make any great promiss for the future of your project other than 'It'll work'
- Relaxeth
- Thou shalt honour the old code and improve upon it with care
- Thou shalt not kill old features and capabilities unnecessarily
- Thou shalt know that for some reaon the other biblical commandments do not work and thus will not be included
- These 7 rules shall be known as the 10 rules of evolutionary software. Why? See rule number 1.
I'd say number 1 and 7 are the most important.
