Presumption of intellect

I’d like to talk about yet another obvious public trend, opposite to the main vogue in choosing SLCM for a software development project.

Have you noticed that different institutions, be they business or governmental units, while communicating with people presume people’s foolishness from the very start? Just try to place your inquiry or claim to, for instance, a bank, or to a phone company, or to a local or federal government, and you instantly would feel yourself complete idiot. Having no real choice, you will be routed through unnecessary silly options, you will be forced to answer silly questions having nothing to do to your exact inquiry, etc.

As is customary, all this is covered up by striving for universality mixed with concerns about enough level of political correctness. Those guys who make decisions just say “We need to communicate with everybody regardless of race, age, sex, health, etc!” So far so good. However, the next decision “Whoever we talk to, let us do it in absolutely the same way!” is quite disputable. You cannot talk to all people in absolutely the same way. It’s obvious, because people differ greatly in their educational level, in their abilities to quickly absorb new information, in their current emotional state, etc., etc., etc. So, to make communication effective and comfortable to the both parties, reasonable gradation of possible audience should be presumed. Unfortunately, those who should do it, never trouble themselves. They rather prefer to consider all the people being at the lowest possible level of intelligence, and thus all the standard options and questions in surveys and in standard dialogues are intended for people on the brink of mental illness.

The result is disastrous, since in fact the brink of mental illness is suggested as the norm for the human society. Just have a look at the vast majority of sitcoms, of commercials, of movies, of fiction books, etc. All this cultural junk food is intended for “normal” members of human society, i.e. (see above) - for the people on the brink of mental illness.

Little by little the society accepts these understated norms, and little by little society becomes sillier and sillier in average. On the contrary: If norms were just a bit overstated, the society would have moved forward to be cleverer and cleverer in average. It’s easy: Try to talk to a person as if he is fool, and you will talk to a fool; try to talk to a person in a clever manner, and you will talk to a clever enough and reasonable individual.

So, what am I talking about? Strange though it may seem, I am getting at software. Absolutely the same excellent result of choosing presumption of intellect rather than presumption of stupidity can be seen in managing software development projects. Try to behave with your customer as with an idiot and you get a non-reasonable, stupid and very difficult customer. Behave with a customer as you would prefer others behave with you (i.e. in a clever way), and you get reasonable, interesting and efficient partner in working on the project. I think, it is one of the main reasons why the software community slowly shifts to use the Agile model, whatever is meant by “Agile” in each particular case and whichever related practices are used.

Rules for Agile wanted

Agile, Lean, Kanban and kindred software practices present different variations on the same theme: How to do software development more effective, i.e. how to provide customers’ happiness with more confidence.

At that, to large extent, lean/agile approach for software development still remains just an idea. It can be called culture, but anyway now it is more about general understanding, about attitude, about something in one’s mind, so let’s call it idea. Interesting, good and prospective, however just an idea. It works perfectly for development teams consisting of almost equal members, each of them of high knowledge, high creativity and high productivity. No doubts that for such an ideal team working for a reasonable customer lean/agile approach seems to be a perfect choice. Unfortunately, 99% of teams are not ideal. For instance, a non-ideal team can be of a following structure:

• creative, knowledgeable and skilled team lead,
• ¼ of the team is creative and skilled,
• ¼ of the team is more creative than skilled,
• ¼ of the team is more skilled than creative,
• ¼ of the team lacks creativeness and skills, however these guys are sufficiently responsible and diligent.

Range of “non-ideality” of a development team can vary substantially, that is why we need definite clear rules of thumb to organize lean/agile processes for an average team.

Similar rules for widely used SLCMs are well known. Certainly, these rules are not carved in stone, and mostly they even do not exist as written lists of regulations. These rules are defined indirectly, being backed by something very well thought out like sets of standard documents/records that should be kept throughout the project and/or sets of special software to support all the stages of the SLC. It is true for the waterfall model as well as for the iterative one implemented by RUP/IBM or by Microsoft.

Existent rules not only make it possible for an average team to deal with a project, but they also eliminate misunderstandings and disputes between developers and customers: The both sides have the same landmarks from the very beginning. Absence of such reference points in the current agile projects is supposed to be compensated by flexibility both of the developer and of the customer as well as by common sense of the parties. Sounds more feasible than it really is for an average development team and an average customer.

So, what we need now to make lean/agile approach really applicable widely in software development projects is backing of this idea by clear rules. This situation can be compared to the early automotive era: Newly invented cars are able to move faster than pedestrians and coaches, that is why we are now trying to use these new vehicles, but it is difficult to drive a car along the roads because there are no traffic laws considering cars, and thus, we easily stir resentment of passengers, pedestrians, coachmen and policemen.

Sudden stupid decisions with grave consequences

Recently I happened to see a new Ice Age movie: Dawn of the Dinosaurs. Well done, with nice and cute characters, but stuffed with absolutely stupid jokes. What a disappointment!

They are our children who are supposed to enjoy this cartoon; and its nice and cute characters are making our inexperienced children think that the characters’ stupid and ugly jokes about farting, about snots, about genitals, are real humor. Humor is a reflection of intellect, and this implies that palming to our children such rubbish off as real humor, the cinema-guys are impairing kids’ intellect. Children’s brains harmed by a cartoon. Sounds terrific, however per se it’s true.

What’s worse is that this harmful stupidity is not necessary. It is not that “We have to provide stupid jokes because they are more natural for an average person”. No human being is by nature predisposed to stupid jokes. To nicotine, to alcohol or to drugs – yes, there exists congenital addiction to these harmful things, but for stupid humor – never; for this misfortune there can be only acquired addiction. Why cultivating it? I could now turn to the questionable path of discussing some conspiracy theories about somebody’s sinister plan to stupefy the society, but I would rather avoid it. The authors of such movies are not members of some evil organization like Ian Fleming’s SPECTRE, neither they are just silly people. Quite to the contrary, I am sure they are nice and clever. Nevertheless, once these nice and clever guys do a silly thing: They decide to produce a movie jam-packed with stupid jokes.

Unfortunately, it’s not that this situation with Ice Age is exceptional, rather not: It just shows an example of a very common thing in our life. Absolutely normal people sometimes strangely tend to show unexpected stupidity in personal life, in common life, and in business. In business such unexpected and unnecessary stupidity, exposed only once, can destroy serious deal.

For several years we used to do a lot of challenging and interesting work for our customer from Boston, MA. Project to project, task to task it was good working atmosphere: Comfortable though exacting. Such happy times lasted until one day the customer decided to hire a new employee for a newly started project. It was a challenging project about developing own BPMS from the scratch, and the new employee was supposed to be responsible for providing our team with all the necessary contacts, information, etc. Vacancy was published, several guys applied, and one of them has been chosen. He was nice and clever, no hint of evil omen, absolutely. As we are in outsourcing software development business, the guy said he needs to visit our premises to get acquainted with the developers. Okay, it was not the first time our customers visited us, so we arranged everything as usually: Meetings, discussions, sightseeing. The guy was reasonable and friendly, he was planning a lot of activities with us, and after several days he said good bye and returned back to Boston. In a few days our customer forwards me the report by this guy. Report is saying that we are a team of unprofessional developers and shameless cheaters; that the project will never be done, and the customer is just wasting his money. Like thunderbolt. I was perplexed and just answered to the customer “No comments”, because what could I comment? Best comments were our previous successful projects. The customer reacted in his own way: The guy was fired, the information about his strange behavior spread among a lot of software companies, and a lot of doors slammed in the guy’s face immediately and forever. Justice was done, but what wrong had been with this guy? Why? He had great prospects, he was moving forward, and suddenly he does something that not only closes these particular prospects, but also makes him persona non grata for hundreds of his colleagues and potential partners. I can only make a try to formulate his sudden stupid decision, it might sound something like: “The project is promising, and it is on the way. Why not throw out the current team then to replace it with my own one?...” Just my guess, but I cannot find any other more or less plausible explanation. Anyway, though explanation seems plausible, the action itself still remains stupid. Like a nice and clever guy has kind of instant brain blackout, and here we are, with all the disappointing consequences.

Unfortunately, such situations happen from time to time in software development projects: Sudden blackout of developer, or tester, or customer, or manager, or whoever, and here we are - long lasting problems for the project.

Lord, save us from such blackouts of our own and keep us faraway from blackouts-prone people, even if they are nice and clever!

Software development business: Peculiarities in delivering results

How software development differs from other types of business? At a first glance there should be no difference whether you sell custom developed software product or some made-to-order material product. Be you a tailor or a software developer, a customer just comes to pay you for a product he/she needs, be it a shirt or an application.

Unfortunately, it’s not so simple. The difference is caused by the nature of product: Software app looks like something absolutely “unmaterial”, like an idea, just a product of somebody’s thinking process. If such, a customer at any given moment feels free to require changing of any single, big or smallish, part of it instantly. When ordering a shirt from a tailor - its model, fabric and buttons are being agreed before the work begins; and as the shirt is made, no sane customer would ever dispute, for instance, number of sleeves or would say that he/she wants a collar to be done inside the shirt. For a shirt there remains only one issue: Whether it fits or not. This becomes absolutely another thing if we speak about software: Post-requirements similar to having three sleeves or a pink collar inside the shirt, at the waist level, are quite habitual.

Okay, software app is something different to a usual material product. If so, can we judge a software app as a bespoke artwork? Unfortunately, my answer again is: No, we can’t. If you order some portrait or a landscape, you would judge the result in general terms: “I like it!” or “It’s awful!” I hardly imagine a person saying that the landscape is perfect, but that grass under the third tree if counted from the left should have been painted 1.5 inches longer. With respect to software app, you would never be surprised with similar judgment.

That is why we have requirements. Long live to them! Requirements are supposed to be if not material, but at least a written base of the agreement between the customer and the developer. However, as the work is done, and the customer comes to see the result, you might hear something like: “Wasn’t it obvious, that this button should have been in the upper right corner of the screen?! I remember exactly that in our phone call I insisted that here should be a pie-chart rather than a table!” And your feeble attempts to refer to the requirements would be repelled indignantly: “It was obvious!” or “I remember I told you!” In this case you would better have either patience of Job, or good law department, or both.

So, certainly you must use fitting formal approaches, but it's not enough. One more "must have" is your personal attitude: We should be totally and implicitly friendly to a customer. Saying ‘friendly’, I mean it. Not just routine smile or even high five (still routine, though), but fair intention to do what the customer really wants, often after helping him/her understand what he/she really wants. It’s not pure altruism: Being really good to customer you are good to yourself. No other way to success in developing bespoke software.

Software life cycle: More freedom than in human life

Software development as one of the human activities is part of our life. Hence, it cannot be completely independent from society, from politics, from prevailing lifestyle. That said, it looks strange to me how common software development techniques show obvious tendencies absolutely opposite to the main trends of the society.

The turning point for the society is 9/11. In the morning of 9/11/2001 I was on my business trip in Boston, MA, and thus I have lived through all that nightmare of the first week after The Turning Point with American friends and colleagues. America was under attack, and America began to defend. Nobody could show the enemy, so the defense activities focused on “security”. Why in quotes - because for a few first months it was “kinda” security. For example, one could not visit any normal eatery in the airport beyond the checkpoint. The reason was that after the checkpoint you should not have any ability to possess a knife or a fork that could become a weapon in the airplane. Good! But after that, in the airplane your dinner was served with absolutely normal metal knife and fork. Yes, now they are plastic, but for the first 1-2 months they still were metal. Was it security? No, rather stupidity.

Anyway, at this point the USA has turned to a new way, and the entire world obediently followed it. The new way - the new rules; the new rules - the new regulations; the new rules and regulations – serious shift in the spirit of the society. Rules, regulations and the shift, all of them were about restrictions and about much more control on how people behave. Strictness grew terrifically: recall, for instance, how in August 2001 people in the US airports used to check in for flights near an airport curb, without showing any ID at all; and compare it to how airport check-in is organized now. The same for lot and lot of other places all over the world. Let’s take just a few examples. Look around yourself at any place in London, and you will see couple of video cameras watching for you. Not the single huge and monstrous London Eye, but thousands of tiny electronic London eyes are watching for you wherever in this beautiful city you are at any given moment. Replace the word “London” in the sentence above for “Moscow”, and everything remains true except that the huge London Eye does not have an equivalent in Moscow. Need more examples? Okay, let’s move to the Eiffel Tower in Paris and walk around it. In couple of minutes you will notice well equipped and armed to the teeth officers looking so impressive, that I would never put in doubt they represent some French special forces. These guys with their rifles are not just loafing around, they watch for those who are. Very close to the tower there is a bus – a local staff wherefrom these guys are managed. So, we easily detect presence of the Big Brother in every country now. The Big Brother does not hide himself now, on the contrary - his presence is demonstrative in each country. To a scale of the whole world it really is the Big Brotherhood, or more precisely - the Brotherhood of Big Brothers. Who would believe in this a decade ago? Just a few years of fear, and here is the result.

I was just talking about main trends that work now for the society. Maybe I became a little bit too agitated: All these obvious and hidden cause-and-effect relations are very interesting, and we really depend on all this. Well, now let’s have a look at the main trend in software development PM. If the trend would have been the same as for the society, we should have seen enhancing strictness and control. Do we see it? No, quite the opposite: In managing their projects, software developers more and more move in the opposite direction, to anarchy. The term seems to be too strong? Let us imagine we are, say, in 1985 and while talking to a follower of a waterfall SLC model we describe him/her an agile methods of 2009. No doubts he/she would have indignantly called it anarchy. Yes, until now we do use waterfall and spiral SLC models. It is not that old good approaches have vanished; I would rather say they are out of style. If 10 years ago following something like RUP standards was somewhat innovative, now it is commonplace, and it looks unprofessional if you abandon RUP-like or MSF-like approaches when they are required. But in these days we are talking quite often about agile methods, about mixed Agile Unified Process, and so on. And we really use these comparatively new PM techniques. What’s strange is that these new “irregular” and “anarchist” techniques have not appeared just out of mind, they are not a result of some theoretical research. They only mirror real needs of customers. But our customers are just people and together they build our society. So what we have is that people in their common life vote for enhancing regulations and control, and at the same time they stand for more and more freedom in managing software projects. What is it? Escape to virtual reality similar to the same in computer games? As if we are burying our heads in the sand, like “Okay, I have to waive freedom in real life, but at least when I work on software, I partly compensate it!”

Software development business essentials

I am in IT business for more than 20 years already, and since 1991 I am a CTO and one of the two co-owners of the Inreco LAN software development (SD) company. It's quite a time. One day this notion has transformed into a sudden idea: why not share my experience and my thoughts about how this business lives; what are the benefits; what are the difficulties; when and how issues tend to become problems, and so on, so on. It is interesting to discuss these ideas with people who would find my notes worth reading.

So, let's go. Where to start from? Ab ovo, i.e. from the basics, from the very beginning.

Although at a first glance SD business looks easy to organize, to manage and to make money on, in reality it is a very difficult business.

It was difficult always: from the very first days when people began thinking of software as of a product, and up to our times when software is considered just an ordinary industrial object. At the beginning, software was something weird, something unusual, and it required a lot of efforts from an enthusiastic seller to open client's eyes to the benefits that might be got after a new software product is developed.

Now all this stuff about selling SD services is quite the contrary: client is able to find an existing software product for any reasonable need. In this situation, custom-made software seems to be absolutely unneeded. Like if you want to furnish your home, you just visit a store and buy furniture. Right? Yes, but not for all people and not for all possible homes. If you have some special ideas and/or some special home, what you need is custom-made furniture. More often than not, such custom-made furniture costs more than the contemporary, available at stores, however it is worth money you pay for it: this furniture is made for you exactly, and it fits your home, your situation and your style completely.

Absolutely the same is true for software: if you just need to type texts or to send e-mails, or, say, to do simple calculations, than you will be fine with some existing cheap or even free software tool. However, a person might discover a need that cannot be satisfied by existing software. For instance, one is struck by an idea of a new promising business that requires very special computer-based activities or some computer-based backing. In this case customer undoubtedly needs his/here own software adjusted to special narrow requirements. Successfully developed, this software can become a locomotive for the entire customer's business. It is not just a theory, we have a number of real examples around us, among our clients. Take, for instance, the Better World Books company: brilliant business idea and its perfect software implementation resulted in successful business.

So, the general concept of custom-developed software turns out to be absolutely viable. At the same time, the key advantage of such software, i.e. its novelty, becomes the first serious obstacle for the supporting business activities. For a customer and for a vendor, the way they move forward from their very first meeting, is much more alike R&D process rather than a routine business procedure. All this makes custom software development so interesting, so challenging and equitably so difficult.