In our previous post on Set based Concurrent Engineering and Software, we discussed how the trick in Set based Concurrent Engineering (SBCE), is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. We also discussed how good design should keep options open, and how this in turn helps us to be flexible and quick to respond to challenges. One approach that many people use [in Agile, Lean and even Waterfall] is You Aren’t Gonna Need It. Like other aspects of Agile and Lean, the concept is simple. Yet, understanding and implementing it can be very difficult. This is because, the concept is against the traditional way. In this case, foreseeing and predicting the future and planning for it has been considered the hallmark of great teams. However, the concept of YAGNI and Do The Simplest Thing That Can Work (DTSTTCW), suggest that its not as much foresight of what will happen in future, but ability to respond effectively to what will happen that separates the really good teams from the average ones. In terms of software, we have always tried to design for “any and all eventualities“, while following practices that do the exact reverse. This is because, we are not designing the architecture for “any and all eventualities” but what we consider to be “any and all eventualities“. If the events unfold exactly the way we want them to, everything goes nicely. The moment there is a deviation, things go astray. In contrast with this elaborate Big Design Up Front, sometimes deferring a decision making to when you have enough information is the best thing to do.

YAGNI is a XP practice which states that “Always implement things when you actually need them, never when you just foresee that you need them.” XP actually takes it a step further and says that even if you’re totally, totally, totally sure that you’ll need a feature later on, don’t implement it now. However, to start with if you have any doubt about “whether you will need it” you should not add that feature. This is because you *might* need the feature in future, but you *might not* either, even if you are very sure right now. If you build the feature, only to discard it later - it would be waste of effort. You might actually need the feature and implement it, but you might need it in a different format and hence, would need to do some work to add to it anyways. Some other disadvantages of doing “what is not needed right now”, right now are:

• The time spent is taken from adding, testing or improving necessary functionality
• The new features must be debugged, documented, and supported
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later
• Until the feature is actually needed it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, the unnecessary feature may not work right, even if it eventually is needed
• The software becomes larger and more complicated
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a situation where you don’t know where to draw a line

As you can see the above are pretty serious issues. And we take them on in a software architecture/ project on the *promise* and *premise* that it would be useful down the road.

The above said, you can religiously follow the letter of YAGNI and yet miss the spirit of YAGNI. The idea of YAGNI is not only to not commit to decisions as late as possible but also do the minimal that could work now. If following YAGNI means that you are actually doing more work “now”, you are not following the spirit of YAGNI. Similarly, the idea of YAGNI is to keep the code simple. If doing “YAGNI” makes your code more complex, you are not following the spirit of YAGNI. For instance, committing to a database is a big decision and you would like to keep the decision open till as late as you can. However, if you already have a database persistence mechanism, not using the same and writing your own file based implementation simply because your feature “does not need it”, would only add chaos. Although, your feature does not need it and probably the feature would take more time using the database persistent mechanism but maintaining two sets of persistent mechanism has two different implementations for same work. We said that “YAGNI is simple” yet “it can be difficult to implement”. For instance, “You aren’t gonna need it” is not about making a method private because “no one will use it, never”. It’s about not putting a pluggable generic templating mechanism for different kind of outputs if your requirement just state “show static HTML”. It does not ask you to be lazy or stop thinking about a requirement. It asks you to consider if you “really need” to write you code in this way or you can simplify it can use it only for the purpose of “this requirement”. The difference is enormous.

Some of the arguments against YAGNI have been that sometimes you have to implement a certain feature, you should factor in that at present. Everything has a cost of doing right now and also the cost for not doing it right now. If the ratio is high, it would be a waste to do these features right now. If the ratio is low [i.e. cost of not doing it now is high], then in all likelihood, the requirements should be prioritized and clear your way in doing something right now. So, lets say you talk to your customer and conversation goes like this:

• Team: We see you have this requirement down in iteration 2. We think that this requirement we are doing in this iteration should factor in that requirement as well and if we took a bit of time to define the interfaces well, we would save a bit of time in iteration 2.
• Customer: Ok, how much time would you save?
• Team: Umn! Maybe 4 hours.
• Customer: And you will need to write that interface anyways?
• Team: Yes.
• Customer: Good! Tell me, if I chose not to implement this feature in iteration 2 but iteration 6, but pick these apparently related requirement from iteration 3 in iteration 2, would the work you do still be useful.
• Team: Umn! Probably yes!
• Customer: So can you code in a way that all the requirements in future iterations are taken care of right now because I don’t know what might need to be done when. Maybe, iteration 2 is pretty stable but not so sure about iteration 3 onwards.
• Team: Yes, we can. We can simply code for iteration 1 right now and not commit either to iteration 6 or 2 feature requirements right now
• Customer: Cool! Would that be YAGNI?
• Team: Err, Yeah!

This is a slightly simplified example, but the crux is that if something has this huge advantage of doing right now, then it should be a priority anyways. The above conversation could probably end with customer asking the team to do it now if the question the team posed was, “whether we should write the comments as we go or later” or “can we commit to a coding architecture right now”. This is often presented in what is called “Opportunity Cost Argument” i.e. loss of cost from other opportunities by choosing to go with only one opportunity. This can be balanced by sometimes asking “what is the cost of not choosing this opportunity right now”.

YAGNI is not a standalone concept and must be used with common sense and following good design principles, good testing framework and continuous refactoring. We like to think of YAGNI as a question and not the answer. The answer has to be provided by you. The secret is to use your brain and not reply on the letter of what the concept says but the spirit as well. This is where Agile separates itself from other processes anyways. The concept does not ask you to be blind. It only asks you to be not be a soothsayer.

Popularity: 31%

Posted on January 12th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction | 1 Comment »

One of the games that we played at our internal annual indoor games was Clue 16. The game was played by two players. One player could think of any person or place and the opponent had to guess what did the other person thought of in series of 16 questions which can only be answered in Yes or No fashion. Now lets say you are playing with me. You come up with “Mother Teresa”. And my questions go like this:

1. I could start by asking: Is it Bill Clinton? The answer is obviously no.
2. I could then ask: Is it London? The answer is again no.
3. I could then ask: Is it South Africa? The answer is obviously no again.
   • And so on…

As you would see, I am going to exhaust my options pretty soon and chances of reaching “the solution” are pretty low. A better approach is to ask the question in “a series of sets”. So it could go like this:

1. I could ask: Is it a person? The answer is a Yes and hence, we rule “place” out.
2. I could then ask: Is the person living? The answer is No.
3. I could then ask: Is the dead person a woman? The answer is Yes.
   • As you can see we are at a much better place at the end of third question compared to first round of reasoning.

In a set based theory explanation, this example is provided through a 2-player in a room game where the first player can only guess objects from a room only. If the opponent has 20 [instead of 10 questions] questions to ask and each question eliminates 50% of options, the game is winnable with certainty in a room containing up to 2¹⁹=524,288 objects². Hence, you can see the trick is to ask the right questions at the right time. It would be very risky to ask the question - Is the dead person a woman as the first question. You could get lucky [we could write an essay on risk and luck too :)] but chances of not being lucky and hence, risks are high. Or, you could ask the question if you knew that the other person is only going to think about a dead person. This is a big assumption, but if you can validate it with some degree of certainty, it is probably worth asking this question. Also, asking questions through “sets” or “regions” rather than “specific instances” is more efficient. You will identify the region as “worth looking into” or “not worth looking into“. This is useful either ways.

As discussed in the web page on set based design, recent work provides evidence that commercial success is correlated with set-based thinking. Also, this can enhance an iterative process even further. Traditional iterative processes first hit on a solution and then try and refine it. Set based concurrent engineering methods emphasize the need to first target multiple alternative/ options and then eliminate the options to converge on a given option. It is a bit of an overhead to start with but the later stages more than make up for it. Further, the risk in the later stages is lower using this approach. This is because you have narrowed down the paths you don’t want to go and selected the most relevant space to look for a solution. And the biggest risk is to look in the wrong area. As can be inferred, this has profound implications for new product design. Hence, set based design approach helps us by:

• Helping us defer decisions till the last minute when the best information is available
• Explore many design alternative at the same time
• Converge designs more quickly

Working with a set based concurrent engineering approach could actually enhance the efficiency even further. Concurrent Engineering is a business strategy which replaces the traditional product development process with one in which tasks are done in parallel and there is an early consideration for every aspect of a product’s development process. This strategy focuses on the optimization and distribution of a firm’s assets in the design and development process to ensure effective, efficient and concurrent product development process to minimize duplicate or repeat effort and risk. If we see an example within a web development process, then concurrent engineering would mandate requirements gathering, analysis, graphics design, architecture design, development, testing and deployment at the same time. This in itself is known to improve productivity. In concurrent engineering, collaboration between various design groups/ departments is stressed. In set based concurrent engineering approach, various design groups reason, develop, and communicate about sets of solutions in parallel and relatively independently. However, they are free to talk to people working on the other sets, rather encouraged to. As various design groups ask questions and find answers to them, they narrow down their respective solution sets. The fact that each of the participants choose a different path means that rich information and feedback to lot of scenarios is available. Theoretically speaking, more the design groups working, reasoning and communicating about sets or options or alternatives in parallel, the better is the chance of an optimized solution solution. Optimized systems generally provide greater overall efficiency. Toyota uses SBCE rather well. SBCE can be used in software effectively as well. One of the places where it could be used is to decide between three-four different alternatives for coding language i.e. answering a question like should we use C++, Java, .Net or PHP. This is how we can go about it:

• 4 pairs can pair program to spike on what they feel is most complicated or strong case for their language in the project
• They are free to talk to each other during their work particularly about how would they evaluate their exercise
• They record their findings and experiences and more than likely for a web based application C++ pair would probably give up and Java pair would probably record findings which suggest heavy overhead and the pair suggests use of Java as non-feasible [and on some projects it could actually be very useful]
• PHP and .Net group would benefit from the findings and depending on the project, the decision could swing either ways

The trick in SBCE, is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. For instance, the decision to change a programming language later in the project is momentous. However, just changing the search algorithm is comparatively not as difficult. From a risk perspective, wrong choice programming language is potentially a huge risk while wrong choice of search algorithm is comparatively a lesser risk. Through the user of SBCE you would like “risky or difficult to change later” situations and decisions to be minimal. Decisions like programming language are probably irreversible but some others like architecture and algorithms can be taken with a view to maximize alternative approaches. A modular approach [SOA, Layered Architecture, Network Protocols, Machine Independent Language] for instance, is known to improve design alternatives. Many examples of modularity are based around the ideas of abstraction and of an interface: two parts make a commitment to how they will “talk” to each other, but no commitment about what happens beyond the interface. Another approach that can help in not doing something wrong is simply not doing it. The implication is so profound and challenging probably because “not doing it” is not considered as an alternative at all. However, not doing it “now” could allow us to do it better when we really need it or have enough information about it. In case of new product development, where multiple scenarios would probably need to be tested, carrying on with multiple approaches can help. Lets take an example of a “landing page that converts”. Assigning one designer to work on the design is a point based approach. Having 03 designers come up with 03 different designs and each tested/ evolved separately would either yield the best design among the 03 or better still through feedback from each other 01 collaborative design that is better than the best in the 03.

As we can see collaboration, reaching the optimal solution, multiple scenarios, flexibility, minimizing waste and efficiency are the key objectives of set based concurrent engineering approach. This align perfectly with Agile.

Popularity: 22%

Posted on January 10th, 2008 by admin
Filed under: Business Alignment, Collaboration | No Comments »