Designing + development

[Tatyana Vuks]

Last weekend I finally read the book by Alan Cooper "The Inmates Are Running the Asylum" that I had been waiting for more than two months coming from Moscow. "Has anything changed?"- you ask? - No, has not...My vision of the world has not been influenced, new and fresh solutions of any risen problem have not appeared on the scene, life goes on just like a week before the book came into my life. And now here is the clue: my web developers would read this book too in two weeks (though I acknowledge that this may seem a bit childish) i.e. there will be an involved group consisting of managers (project managers or project development managers), front- and back-end web developers, coders and designers. My question is if anything will change within this group, i.e. attitude to work, to the projects developed, to our own future?

Even without Cooper's theses everyone in this world who is related to the IT speaks about the necessity of designing and unprofitableness of the so called ersatz designing. In real IP projects project managers and developers have always been arguing about the designing aspect that looks close to such dialogs: "Let's do a test module fast" - "Let's first design the whole project" - "no, that's too long and unprofitable" - "But in case we have to redo the whole project that you will have to develop on the basis of this rest module will turn to be more unprofitable"; this situation repeats day by day, almost in each sub-group of our software developers.

Someone more obstinate and self-confident would insist on a preliminary designing and creating the correct module, someone would prefer creating tabs in the database adding fields and links ignoring the database work optimality and run query speed. Their logic is simple, they do what the customer ordered. They don't care about the query running from 40 to 90 seconds that makes an inexperienced user think that they have done something wrong whereas an experienced one thinks that Windows is being buzzed and closes the browser window. So, let's have the designer seek for the solution of user's interaction with the tools.

So, the solution lies onto the designer's shoulders. They add such messages as "Please, wait…" to have the user stick to the computer while the data are getting generated. However, a user may not notice a text message on the screen (it is natural as they don't expect for a message, they expect for the data show up), so the designer needs to draw their attention with some animated picture, a so called "pre-loader" (BTW, let me present you a fine tool for numerous small and smart pr...) that are generated according to your requests concerning color and background.

What a pleasure to see that a task that should have been resolved several months ago but neglected by the customers suddenly pops up so I can say one more time "That's what I told you before" and this time I am finally heard. So we take a common decision that this service would be useful (the customer was just unready to add this service last year) and we have just a mere trifle to do - to add one more form to the interface.

And if I hadn't been heard last autumn, nothing would have worked; we had either to deny this idea or to change the whole basis of the project completely. The funniest thing was that the customer was not able to determine the target of their project themselves. As for me, I immediately designed the project in my mind, determined the target group and what features would be required in the nearest future. So, the customer needed to check a created solution during several months, to use it with real data and live money. And finally the customer saw the aim pretty clear.

I know that miracles seldom happen. Usually a customer does not put a clear task i.e. they cannot explain their vision of the project to the project developer who cannot give a strict task to the web developers. Web developers are not eager to display their zeal, creative capacities, intuition and to develop the tasks that were not determined. A bad project, a useless tool, a defective service is always easy to develop. But the correct understanding of the target may guarantee a good development. That rule is applicable to IT-projects and to everyday situation.

Here is an example from a common life:

My child is given money and a task to buy about 500-600 grams of smoked sausages. Then I leave to work and will be back late at night. Meanwhile my son goes to the store and discovers that they don't have smoked sausages. There are several decisions to take in this situation. My child decides to buy 300 grams of less tasty and quality milk sausages. Why? Because he takes the task not as "to fulfill the errand given by his mother" but as "there is nothing to eat at home, so I must get some food". Here is the difference! This is time to show up initiative. If my kid had not bought anything I would have had an empty fridge in the evening, and as it would be too late to go shopping, we would have had nothing for dinner as well as for breakfast. If he had bought sausages of worse quality but of the quantity indicated by me we would have had 600 grams of inedible food that we would be forced to eat for several days. So the decision taken by my kid was the best under the given circumstances and ensured the minimum to get over the crisis. Probably next day we would buy meat and have time to cook it, but even we would not, they would bring sausages of high quality, in any case the crisis will not come. My son determined the target correctly.

Errors of insufficient designing as well as errors of existing designing do exist in almost each first project. A perfect analysis can be held for a tiny little project with a minimum number of input data and single output data.

It is impossible to consider all the details at the designing stage as there is always a risk that something will be missing. That's why developers are to involve their ideas, creative and logical thinking to a greater or lesser extent.

Should I mention that we all deal with different developers? Some developers execute a given task diligently and laboriously following the instructions strictly. In three months they will find out that the database is far from being perfect, that it is wretched and of little use. So the developer says "Give me then another task, I will redo".

There are meticulous and obstinate developers who don't set about working until they quarrel with all the customers, project-managers and other supervisors but finally get what they need - customer or project managers start thinking themselves over the task they give. And finally among developers you can meet dudes with well-working intuition who never discuss the details of the project and accomplish their task so when it comes to adding new features and services, here they are! the task is easy as a pie - only one form, two check boxes and three hours required to finish the revision.

Of course any task should be approached correctly. Of course, the frameworks of responsibility should be shaped in advance, where a project manager should assume responsibility for the designing quality and a web developer should be responsible for the programming process.

But in real life an exaggerated formalization in most cases results in deterioration of the project situation. So, we may and should expect a web developer to show up their initiative (within the frameworks of the given task). Any web developer will have to take decisions and assume responsibility in any case to a greater or lesser extent.

Domestic associations:

I ask my child to buy a pack of juice. That's all. Then my child is analyzing the situation on his own.
He
remembers that I have been buying apple juice and sometimes carrot juice lately. So he should choose between these ones. He saw me buying juice in two-liter packs. So, he needs to buy the same two-liter pack. He counts the money received and sees that the amount corresponds to the price of a two-liter pack of juice. He comes to the store but finds out that two-liter packs are absent, the juice he needs is available in one-liter packs only.

What a solution he can take:
1. not to buy anything because the solutions required under the task are impossible to achieve.
2. to act at his own risk i.e. to buy the juice required but in another packing, different from the one I need , i.e. in one liter pack.
3. to act at his own risk and take a decision that is mostly approached to the solution required i.e. to buy two one liter packs.
The cost difference between one two-liter pack and two one-liter ones makes several tens of kopecks. But the kid takes the third decision. Actually whatever decision you choose from the three ones above, each of them contains inaccuracy towards the given task. The first one leaves us without juice at all, the second means less juice than required, and the third one supposes we pay more than it was discussed at the beginning.
My child has made his choice and is ready to assume responsibility for his choice.
The task is so insignificant that no one will contact the project manager to correlate initial conditions and to review the technical task. If we follow this principle one day we will not be able to get up independently without listening to the instructions what leg you should put into the slipper first.

You may think that I am trying to justify the supervisors that don't want to pay enough attention to preliminary designing trying to put the responsibility for the right choice onto the shoulders of the web developers. No, I am not and I won't. But sometimes I encounter errors that don't inhere to the people considering themselves as adequate and logical developers capable of taking wise and serious decisions.

BTW, here is an announcement of the 4-th Usability bulletin issue where I found a link to the translation of Scott Berkun's article "Why software sucks?"

How good things are made
When you create you are exercising the greatest power in the universe: bringing something that didn't
exist before into the world. Making something for others is a gift. Few people in the world have the privilege of earning a living by creating things. If you build things for yourself, you are both the creator and the consumer. But if you are making things for others, you don't receive the gift: you are the gift giver.

Most people suck at giving gifts (even to themselves: most of us don't even know how to make ourselves happy, much less others). We could all fill rooms with the lifetime of junk we've received as gifts from people that: were careless, thoughtless, insincere, cheap, indifferent to or ignorant of our needs, had bad taste, no skills, or simply didn't know us well enough to give something we'd enjoy. Bad software is a bad gift. All of the failures that lead to bad gifts apply to bad software.

Good things in the world come from people that have the gift mentality. They do care about who they are designing for. They are sincere about trying to build something that will satisfy a person's needs. They are willing to expend time and energy refining their thinking and developing new skills so that when they are finished they can sincerely offer what they've made to the world as a good thing. They see their work as a deep expression of generosity and as an attempt to live up to their own ideal of quality and workmanship.

Good programmers, designers, architects or creators of any kind are simply thoughtful. They are so passionate about making good things, that they will study any discipline, read any book, listen to any person and learn any skill that might improve their abilities to make things worthy of the world. They tear down boundaries of discipline, domain or job title, clawing at any idea, regardless of its origins, that might help them make a better thing.

Source: Blog NunDesign