OK, so now what?

Now we begin by breaking the big task into several one at a time steps.

1. Mapping

Mapping the problem domain. It is essential to understand the problem and by understand I mean the sum of every possible detail that is known by now to anyone who knows anything about it. Your job is to make a map of all the concepts, needs, and desires for project now and in the visible future. This is not by any mean the design of the task and it is not just understating the requirements. We go deeper and wider than the requirements. We need to know everything. Your software might need to support what the product managers want and also what they don’t know that they want or won’t bother/not skilled to go into such details. But  software is details. You must draw again the map which explains the problem domain even if it was prepared by already. You have to draw it again to make sure everything is clear and to give yourself a chance challenge every bit to pieces.

There are standard tools that can help:

1. Domain analyses  http://en.wikipedia.org/wiki/Domain_analysis
2. Use case diagram http://en.wikipedia.org/wiki/Use_case_diagram

An important remark is that mapping the problem is not equal to designing. The actual design might not be even remotely close the domain analyses. A composition connection for example might be transformed into a class with members into it. Although the end design might be just that it is important at this stage to view this connection as an abstract idea of a system which is strongly coupled and not as  a shorthand to better documented software which is a result of using code generations tools.

2. Breaking

Breaking into separated responsibility areas. It is impossible to find a god solution just by treating the task as one. It must be break down into as independent as possible pieces. Divide et impera. The paradox is that the whole can only be visible after all the parts are removed and ordered. So, before even begging taking moving to design it is essential to know what the software parts it contains. Check out the separation of concern concept: http://en.wikipedia.org/wiki/Separation_of_concerns. This is an OOD concept but it also apply to the analyzing domain.

3. Evaluating

Now that you know the problem domain well and you have some idea of responsibility areas it is time to begin the evaluation. At this stage it is important to bring as much solution options as possible and to evaluate each. How the evaluation is done? I suppose that there is more than some personal preference and experience involve. The import thins is to actually do the evolution. More often than not the first solution is taken when a much better one was there just across the corner all the time. The evaluation can take into consideration the complexity, risks, skill set and time frames. Kasporov, the chess master is evaluating chess setup with material, time and quality terms. Those terms and others can be applied to software evaluation.

4. Planning

Planning before designing? I know it sounds odd but design also needs planning. Have you heard of over design? Most of software management systems today have adopted the iterative concept. Instead of everything designed, written and tested at once the progress is instead done in several iterations. Each phase includes mini designing, writing and testing where the idea is always to stayed focus and to avoid spending too much energy where there are not needed.

The aesthetic part of programing  rarely becomes important enough to get any attention at all. I don’t remember seeing in design documents sections dedicated to the look of the classes and during design review sessions I never heard lines like – “the solution should work but the aesthetics is not brilliant, give me something prettier please”. Still, designing, using the artistic meaning,  is present in creating any product whether it is a software product, a software source code, automobile engines, automobiles or just cleaning products.  Of course,  aesthetics gets more attention when designing sport cars than it gets for designing soap and still it is there nevertheless.

Source code isn’t created to sell its looks . It was made to perform some logical tasks. Same holds for automobile engines. Still, the process of getting to a good design of a sport car is very similar to the process of designing the technical, dirty little pieces of software. In both cases there are many different ambitions and it is never possible to satisfy everything. In the end there is going to be some trade-off and compromising and the creative process of adapting and changing the formation till the compromise is solid is the design process. There is always more than one way to skin a cat http://justapipe.wordpress.com/2010/07/19/skin-the-cat-once/ .Aesthetics plays a big part in designing sport cars only because sport cars has a high requirements in regards to aesthetics. It is just one of the items in the wish list along with more technical ambitions like speed and power. And, although aesthetics is not going to be on your requirement list for software design it is still there, in the background.

Decisions like more classes, big do all classes or small cohesive elements are influenced from aesthetics and not only from functionality. It is no too speculative to presume that better aesthetics would result in better functionality. Aesthetics, I sure that biologically as well as practice, is a shortcut for getting to better functionality. In biology, better looking woman or man is usually corresponds to better gene pool and therefore is more attractive. Better design, only by the aesthetic parameter would make it easier to read and maintain because  we would know immediately where new additions belongs. When all the classes are arranged  in some nice geometric form where more important classes are bigger (heavier) it is much easier not to make mistakes.

The opposite where everything is cluttered together… well, I don’t need to tell you about that.

When I get a design document where the artistic design elements are working well together I know it that it is going to be a deign that works and last judging only by parameters like space, layout, flow. Parameters that naturally belong to areas like architecture and commercial product design.

Aesthetics should become more explicit  in design reviews and not because we like to pretend that that software development is more creative than other areas like architecture but purely for practical reasons.

This function is useful for calculating bonus for late shifts and as a beginning level programing interview question.

/* shouldGetBonus
 *  Assuming less than 24 hours shift :), return true when the shift hours overlap bonus hours.
 *  E.g. a shift between 22:00 - 04:00 when the bonus hours are 02:00 06:00
 *  For convenience this method accepts only exact hours range without fractions but the same principals
 *  which apply for this method can be applied for fractions of hours and for longer than 24 hours shifts.
 *
 *  This method is given as a demonstration of finding overlapping range of circular ranges and recursions.
 *
 *  This code is free to use for any purpose and without ant warranty.
 *
 */
 public static boolean shouldGetBonus(int shiftHourOfDayBegin,  int shiftHourOfDayEnd,
 int bonusHoursRangeBegin, int bonusHoursOfRangeEnd) {

 // When the end of the shift is less than the beginning of the shift, it means that
 // midnight has been crossed.
 // Split shift to parts before and after midnight
 if (shiftHourOfDayEnd < shiftHourOfDayBegin) {

 // Recursive call to the first shift part
 if (shouldGetBonus(shiftHourOfDayBegin, 24, bonusHoursRangeBegin, bonusHoursOfRangeEnd)) {
 return true;
 }

 // Recursive call to the second shift part
 if (shouldGetBonus(0, shiftHourOfDayEnd, bonusHoursRangeBegin, bonusHoursOfRangeEnd)) {
 return true;
 }
 return false;
 }

 // Same as with shift range - split bonus range hours to parts before and after midnight
 if (bonusHoursOfRangeEnd < bonusHoursRangeBegin) {

 // Recursive call to the first bonus hours part
 if (shouldGetBonus(shiftHourOfDayBegin, shiftHourOfDayEnd, bonusHoursRangeBegin, 24)) {
 return true;
 }

 // Recursive call to the second bonus hours part
 if (shouldGetBonus(shiftHourOfDayBegin, shiftHourOfDayEnd, 0, bonusHoursOfRangeEnd)) {
 return true;
 }
 return false;

 }

 // Checking overlapping condition
 if (shiftHourOfDayEnd > bonusHoursRangeBegin && bonusHoursOfRangeEnd > shiftHourOfDayBegin) {
 return true;
 }

 return false;
 }

So what’s there to argue about when all search engines implement the same well known theory?

A lot apparently. Every detail actually has a big impact on performance,  product and quality. The best choice is also context dependent. What is an excellent choice for one context is a total disaster in another. Searching documents on the web is not like searching addresses which have short, rigid and repeating sequences of words.

Arguments like this one happens all the time. Companies are shifting their attention to new areas and paying  the tuition for learning and tailoring a unique solutions. Later, the same developers or external consultants come to new insights. That’s the nature of the business where the requirements are changing all the time.  Obviously the ideal approach is to learn as much as possible as soon as possible but usually the research resources are limited, especially if the product is not in the center of attention.

And here is the conclusion – there is more than one way to skin a cat.

Each approach has its cons and pros and the decision takes are always based of what we know at now and our predictions for the future. When any of the first assumptions changes the direction of development must be carefully reassessed. Ideally, the differences, taken the evolution is done often enough, should be relatively small and the appropriate adjustments can be made. Sometime, however, the present or the future predictions is changed so much that a whole different way should be taken. In those moments, you realize that you are no more skinning the same cat, or worst, not skinning at all while should perform another task – maybe not even violent (like using a third party search engine).

Those decisions are the important one. As long as the same cat is skinned the technique doesn’t matter so much. Those arguments can a nice for a coffee break but in the end it is a waste of time. The other type of arguments is critical. In my opinion the competency of the management staff is visible when they show the ability to tell the first argument type from the other one.

When you are required to write a feature in about 2 weeks, do you:

1. Write the feature in one week. Documentation,  meetings and e-mails in the other week?
2. Spending 3 days, designing a better infrastructure. Failure attempts to write the new infrastructure in 5 days and spend 2 days to get to the dead line with a buggy and half cooked feature?
3. Write software that protects against 4 special cases which were not covered well by the requirements in 4 weeks?

‘C’ are the algorithm developer and researchers types. They need more time but they do more including true impressing staff that no one knew or cared about.

‘B’ are the technological gurus. They know about new cool stuff. They know every hidden feature or goodie in Java or C++. They care about infrastructure and design like no one else cares.

‘A’ are normal average workers. They do average job well. That’s all there is to say about them.

It seems in first glance that we just need ‘A’s. CEO often complains why what they wanted isn’t get done while some of the staff is busy with all sort of new initiatives. In the end it is true that the company doesn’t sell algorithms or infrastructure design ideas. The company sells products and features and you need the ‘A’ people to deliver it. So why bother with the ‘B’ and the ‘C’?

Infrastructure, as even some of the CEOs understand, is needed to:

1. Make the production capacity better. Sure, you can hire another 4 ‘A’s to deliver 4 times faster. Well, not exactly. Maybe at the beginning it is possible. After awhile the code base the complexity gets so big that sometimes even 20 ‘A’s is not enough to keep up.
2. You need someone to understand in technology or otherwise the company could not be taken as a serious technology company. The gurus would get to correct decision before the ‘A’ people would throw money in 4 wrong directions.

Bottom line – ‘B’ half the time working on something that is not needed but they create a 4 times more productive infrastructure and get to right decision on the second attempt, instead the forth attempt of the ‘A’ people.

So , the net worth of ‘B’ is 4 /2* 4/2 = 2 ‘A’.

‘B’ are the macro people. They see the big picture and they are needed for the purpose of being able to get out of corner where the ‘A’ people and the company are stuck.

‘C’ is my favorite. ‘C’ are the opposites of ‘B’. Those are the people of the micro. What they see in the atomic level, no one can without special microscopic equipment. Although they need more time they also deliver much more and that’s because the other 4 special cases are also required whether the product department is aware of it or not. So instead waiting for the customers to complain they actually are preventing it to happen in advance. So in the end their value is much more than the 4/2. Sometimes keeping a customer can cost a 4 ‘A’ salaries. So the real value of ‘C’ is highest among all the other personalities. The amount of dedication needed to be a ‘C’ type is exceptionally higher too and in the end all they can show for is a lot of experience in some tiny niche. So don’t judge so quickly next time because the ‘C’ types has proven to be capable provide the values of a ‘C’ types which as explained are really valuable.

And what if you are an ‘A’? In that case you are redundant. You are going to be replaced by cheap offshore labor or younger ‘A’ sooner or later.

Did you think this quote is obsolete? Perhaps in regards to politics it brings back warm memories from the the cold war era, when we were children back than at 1984. But, since this is still a good quote, and I hate to waste a good quote, I think it is time to reapply it to information technology. Information is the records of history, of the past, and technology is what controls it. Did you really commit that transaction? You think you did. Let me just make a minor modification of the past for you and no… you didn’t. So you claim you definitely remember, and how do you explain remembering being with Angelina Jolie last night? I mean, without offending, this looks a bit unlikely. is it possible that this is just your imagination? How can you tell if it is not just a dream? Like the transaction story. We’d like to help you but there is just not enough evidence.

Controlling the past, controlling the future, controlling information, controlling. Controlling is always about rationalizing and explaining the past but every time we try to draw a conclusion from the past, to learn from it, we discover it is’t there anymore. Yes, the past is changing.

Would you try to perform a mental experiment. What were your team major achievements this week? How about two weeks ago? Repeating this experiment often with my colleagues I am able to draw an empirically sustainable theory – every one of them can’t tell for certain for more than two weeks back. Asking, what has your team achieved in the last 1/2 year is pointless. The speed of events is just too fast. We have to focus on now most of time. But how could we influence the future, and find sustainable solutions if we don’t have the past available anymore. Are we doomed to repeat the same mistakes again and again. One of the definitions of insanity is repeating the same action again and again and expecting different results.

For many of my colleagues, making the effort to keep a journal which records the major events each week is a burden. Explaining failure, especially a failure of a repeatedly nature is the burden to me.

Typically you would write less code with python. The structure of the language has a modern minimalistic look which would make it easier to read. Java is considered a factory language designed to produce loads of not very sophisticate code which is the what the solid foundation of the software industry is built on. At least that’s what they are telling us.

The truth is that it doesn’t matter. At least it doesn’t matter so much. Definitely, the passion of some gurus when they are advocating for any of the dead languages which are redicovered occasionally is exaggerated. Languages are highly overrated.

My view on writing code is that a program is a form of explaining, convincing and telling a story. It is a way to organize ideas in a structured and clear way with the purpose of persuading to do things in a way the programmer believes should be done. If the reviewer remains with too many open questions, a deep feeling of doubt in the design logic and the overall completeness of thinking and with a desire never to touch your piece of code again, not even with a stick – it means, your message didn’t get through. Your tower of ideas has collapsed while you are watching trembling and poor from the side like realizing half way that what you are about to say is really stupid and hoping you are not going to get caught as you continue to talk.

The selection of language is not a guarantee of avoiding any of that. I believe that the contrary is true. Writing well with one language is going to guarantee that you are going to continue to write well with any language.

Great ideas like this one are typical to our product department. It looks smart on first glance. Let’s point out the strong points:

1. Other adults don’t play these games – no competition
2. No one have though of it – it is original
3. Who wouldn’t want to return to his childhood? We have a strong need – a market
4. It’s cheap  – it’s cheap
5. Everyone is familiar with the rules – good usability
6. We can create a community of players – community
7. You can invite your friends – social network

Sound like a winner, isn’t it?

Eventually, someone would ask, why it is necessary to arrange the whole show? It is not more than an expensive ad for the FIFA game. Why watch while we can enjoy few more hours with the real game?

For now, let me just say thank you for the FIFA game because without trying it I would have never understand what’s going on the real game.

Actually it was just pure luck that I have even tried to play the FIFA game in the first place. Since I never used to like football I didn’t think giving FIFA the video game a chance. And I did, and ahh, yes, it wasn’t fun.

I didn’t understand how to play the game. So I tried again and again till finally I was able to give a good average play. Just had to understand what everyone sees in the game that I didn’t. And then, after maybe 20 times,  it was fun, at last.

But as not fun as other video games.

And playing football is not as fun as other sports too.
Why everyone loves football so much I don’t know and I am not going to try to find out.

Tennis is more fun.

The unavoidable conclusion is that doing what everyone else does would make you a good average player at best and it is not going to be so much fun.

That’s why I became a programmer in the first place. Everyone hated it.

These days I sure would not repeat the mistake.

I would try to become a tennis player instead. or something.

Today is the longest day of the year after all (at the north hemisphere).

I am not going to put here an illustrati0n of the sun.

Go outside and look