Some 18 months ago I started writing a post which was (sadly ?) forgotten called “Programming as if the user experience doesn’t matter”. Today I came across this wonderful post which wisely says
Stupid is predictable; predictable is learnable; learnable is usable.
Perhaps the time has come to dust off my post…
Hunger is a primitive urge that requires immediate satisfaction. It commands your thoughts and demands a short term remedy often ignoring the most obvious consequences. I find it extremely odd that it is so commonly used by the industry as a positive quality sought for in candidates particularly for management/sales positions. If hunger for success resembles hunger for food, a hungry employee (or worse manager) is likely to cut corners, to ignore longer term goals, to disregard his co-workers (or worse, his subordinates) and generally to dutifully serve the company only when it is aligned with his immediate goals. Loyalty and strategical thinking should not be expected.
Indeed hunger may foster some creativity but it can not seriously be considered as a state you want to stay in. And frankly who on earth would consider starving himself just to keep himself motivated? Hunger is basically a primal urge that can overtake your mind just like that other primal urge that assumes control over your mind. And you don’t see job descriptions looking for “horny managers”, do you (although I guess many would apply) ? This isn’t just an unfortunate choice of words – it is very much consistent with the current “set of beliefs” of the industry. I can go on and on ranting about the lack of values, short-sightedness etc. but I guess the point is clear.
I’ve literally read Frank Herbert’s Dune dozens of times1. Other than being a fantastic SF book it contains some pearls of wisdom that apply to many situations in our day-to-day lives.
One of the quotations I like the most is
Give as few orders as possible. Once you’ve given orders on a subject, you must always give orders on that subject. – Duke Leto Atreides, “Dune” (Frank Herbert)
When leading (ahm, and yes, managing) development efforts I’m often in a situation when a developer asks me to make a decision regarding her work. If I think however it is an issue that falls well within the territory and responsibility of the developer, I try very hard to let her decide. No, I’m not trying to avoid decision making (always a pain), I’m just trying not to “give orders” (as the Duke puts it). You see, if I make the decision I have in essence minimized the (good) responsibility areas of the developer and her ability to freely progress in the future. Now she has less space to operate in, less room to express her ideas, and she is becoming more a “doer” than a “thinker”. So overall the freedom of the team to develop as they think is right is hurt. And if that wasn’t enough, your decision on outcomes of this decision (like the evolution of that particular feature or design) will always be required, and the scalability of the team as a whole is affected.
This practice, of minimizing the decisions you make for your developers, is even harder to follow when you have a strong opinion about something one of your developer is (or is about to be) doing. For example he is about to write some fancy lock-free data-structure while you think plain old synchronized hash table will do. As long as his plans are not colliding with the overall design and the extra effort isn’t dramatic it is better to let him do what he feels is right. Above all, it is a local decision within his territory, an area which he surely knows better from anyone else. If you force him to use your solution, don’t be surprised when every little obstacle he encounter will result in him calling you to fix it for him and again you turned a thinking programmer into a robot that just follows your orders and avoids exercising his brain. A living REPL .
Indeed a mistake can be made when the decision is the wrong one. So what? Didn’t the developer and hence the team just enhanced their experience? Hey, aren’t you still making fullish mistakes? As long as the mistake is well contained within acceptable boundaries no real harm is done. It is your responsibility however as the lead to make sure such boundaries exist, so mistakes are quickly identified.
True, this practice can’t be applied with less experienced or less capable employees, but I try very hard to make sure everybody who works with me is at least capable of making smart decisions regarding her own work. Otherwise, why hire them?
1 Incidentally, I once read that the Hebrew translation of Dune exceeds the original. That’s a bold statement to make, but even if it isn’t true, the Hebrew translation is very very good.
Developers love to optimize. They love it so much they will often engage in it too early, a habit so bad it will frequently back-fire. But even the mature ones will happily pursue that ultimate sweet goal – making that code run faster or use less bandwidth, or consume less space. We all want that warm fuzzy feeling of achieving 53% improvement, and then 15% and then, pathetically, the last 2.71% .
It is probably due to the immediate and accurate feedback that optimization gives us. It is measurable and involves no smart-ass manager’s opinion or some client’s subjective impression. It is the perfect ego booster. It is also an enjoyable process during which we can test some tricks and resurrect our old passion for data-structures 101.
The flip side of it is bad, ugly, non-reusable code. That is, most of the time optimization and especially micro-optimization, will result in transforming the naively elegant structure of the code into a hairy beast that runs faster but smells. A harsh fact. I was always amused to see that programmers write “dense” code when trying to optimize a lot. That is, for some odd reason the variables names are always a single letter, with less spaces per line sometimes even fitting multiple statements into a single semi-colon separated line. As if by taking less space the code would run faster.
Unless of course you have meditated on it long enough to understand that there is another, even more elegant way of solving the problem at hand. And not only is it elegant it is simpler and faster. This is macro-optimization and is the true reward of programming—solving a problem the second time after reaching enlightenment. Sweet indeed.
I can’t help admiring the technical achievement in making an Ajax-based browser-resident Outlook clone. I also can’t help thinking how I consistently failed using Outlook as my email client [1] . So, do we really need such an application? Isn’t gmail enough? I wouldn’t be surprised if despite the latest hype surrounding Ajax applications we’ll really be using those who prove to be simple and functional rather than those which mimic their desktop ancestors with great self indulgent.
A recent Nielsen article confirms this. The naive browser interface that we’ve grown accustomed to is a blessing for many applications. It makes simplicity shine by forcing the developers to abide to the html’s restrictions hence forcing us (the developers) to actually refine the functionality and the user experience so it’ll fit a (relatively) limited UI platform. It is also by now a standard platform which is known to be powerful yet simple enough for a great deal of application.
Indeed elegant (read simple and concise) user experience is not outside of the Ajax reach, yet Ajax developers are much more likely to jump through hoops if they only can. Surely you’ve seen a grinning programmer after he finally got to use that library/API everybody is talking about. Frankly most of the time we are concerned more with our (programmers) own delight than the users needs. While Google did miracles (as always) with gmail and 37signals are, well, 37signals I doubt will see a lot of such fine Ajax based applications.
[1] ...and run away screaming into the loving arms of Thunderbird or M2. Actually MS Project also proved to be a software I simply failed to learn how to use despite repeated attempts. I honestly tried to overcome my inherent inclination to use an MS product, but these two applications turned out to be so annoying, so rigid and so different from what I expect from an application that I just gave up.
Nothing is more dangerous for the development process than losing control of the project complexity (think of a star collapsing into a black hole). The team must develop a feeling for complexity and know when a task should/can not be done or when a technology or a design should not be used or followed for fear of complexity taking over.
There is also a soft, human side to it—developers who are uncertain of the application are likely to make grave mistakes anywhere along the development process. They are also likely to pass on this message of uncertainty when working closely with the client. Then you are dealing with suspicious clients…
The “keep it simple” meme should therefore be understood as Keep it Simple to Understand and Control or “keep it easy”. Beware of simple solutions that may be correct and even elegant but are too abstract or just not easy to understand.
The “keep it easy” mantra is best understood when projecting it onto the development and integration process. Everything that simplifies the team’s life should be seriously considered. The opposite is equally true (or even stronger). Therefore the following holds: When a development process can be automated or made rigid (i.e. less prone to human errors) at reasonable cost (here lies the trick) it should be!
Extreme Programming refer to the confidence one should have in the software that is being developed. How true. It is vital to make sure programmers feel they are standing on firm ground. The verb “feel” is used not to suggest any kind of denial or masking the truth, but rather to the actual psychological state of the programmer. Some degree of inconsistency surely exists in the software and a programmer can undoubtly be unaware of some of it. Nor can a programmer be expected (by himself or others) to have a intimate familiarity with the all the dusty dark corners of the code. Yet he should feel confident to the degree that he will not resent or fear changes. Otherwise changes are likely to be deferred forever making room for ugly patches that are followed by a flok of bugs and yet another decrese in confident.
To be continued…
Note: The following paragraphs were written a year before I became aware of Joel Spolsky wonderful writing on the same subject
“What a mess, this has to be written all over again”—be suspicious (very suspicious) when you hear someone (possibly your inner voice) says a piece of code has to be rewritten. Most of the time it is a symptom of incomplete understanding of the problem at hand or of the code you are referring to. Assuming the original code was not written by a complete idiot (which is more often than not the case) you’d better give it another shot.
On the other hand the “if it ain’t broken don’t fix it” mantra is dangerous also. Wiser men (than me, ESR for example) said that sometimes you only understand a problem once you solved it. Often the first iteration of the code works, yet it offers a less crafted design than you want (and now know how to do) or an awkward interface that messes things in your code or a problematic implementation (inefficient, inflexible, not thread-safe) that imposes limits on its users. Rewriting it sounds like a lot of work, but refactoring it sounds like much less work (even if the two coincide) and is probably what you should do.
Experience (mine) shows that refactoring is a much shorter task than rewritting especially since you have less bugs to deal with (and they are mostly known) and the testing process is much easier (as you already have real users or clients of the code). It is comforting to discover that such refactoring usually pays itself (in terms of development time and debugging) immediatelly and therefore should not be considered a task for a rainy day but rather a routine task. Problems that are noticed today but deferred are not likely to disappear, so when a major design flaw or incomplete implementation is discovered and ignored don’t be surprised to see its agly head pop up in some lesser expected places.