Monday, April 30, 2007

[off topic] Driving Principles of Programming

I often asked on how software development works. To most people unfamiliar with all stinky innards of development process, figuring out how to get anything out of developers is very very tricky. Sometimes people see logic behind what I do - but often they are lost when trying to deal with me.

So as an insight into developer's head I would explain shortly here two of my software development principles. "Shortly" and "two" - because I have managed to date to formulate only one (second) of them and first was well know before I was even born.

1. This is grand principle which regulates lion share of decisions made by software developer. LAZINESS. Some think of it as of bad habit, but in as old programmers' proverb goes to find simplest solution to a problem, assign the problem to laziest programmer you have. In development and programming, laziness is source of all simple decisions which are often by outsiders are seen as "original" or even "genius". To programmers - it's just N days of work saved.

1a. Corollary. In development team with no lazy people, one would hardly see any innovation - or properly working program. After all, non-lazy people can make even pigs flying.

2. It just dawned on me recently and I have managed to formulate my second most used programming principle. EGOISM. (I would claim nothing and rather expect that somebody already did research that before me.) The principle is very simple: make something what would be useful to you and most likely others would find it also useful. Check the Unix made of thousands of small and big utilities - most of the utilities were initially developed for particular purpose of its author himself. But later were also found by others to be useful. Well, Unix itself was made for very particular purpose - and none of its developers even thought that Unix would catch up. Yet it did. Why? Because first and foremost it was useful to its creators. They didn't cared much what others did with it - how egoistic of them!? ;)

2a. Corollary. Excessive non-egoistic programming results in piles of abstract interfaces made to abstract other interfaces which abstract other interfaces. They do not do anything in particular - they are written often because people are told to write something. It is hard to make something useful - if you are just a little gear which needs only to mesh with other such gears. And to mesh better - we need more interfaces, abstraction layers and level of indirection. It also happens to be a generic sickness of many successful projects which in beginning "just work", but authors along the way get bored and start adding needless minor features (by request of vocal user minority) which in the end obstruct core functionality. Program was started as something working - thus became popular. Later on to satisfy needs of few others (here ended the egoism!) features added were not needed by authors themselves (nor (as usually!) were properly communicated by end users to developers) thus ended up being implemented poorly.

That's it for today.

No comments: