Natural mapping: The author says that when designing systems, you should make use of natural mapping. What does it mean? For example, lets say you were designing the switch board for electrical appliances in a room. One way and the common way to do it would be, to place all switches in one straight line. Now, this means, that the user has to remember, which switch does what. If you use natural mapping, you would design the switch board in such a way that the switch position on the board mirrors or maps the physical location of the appliance it operates in the room. This way it is very intuitive, which switch goes to which appliance in the room. Another great example is the gas burner switches, that I struggle with almost every day. I can never remember, which switch is for which burner. The author suggests some beautiful designs to map the actual burner position to its switch. Doors are a source of constant pain when operating. Wouldn’t it be nice to have a flat plate on the side of the door that needs to be pushed to be opened and a vertical bar for ones that need to be pulled. Why is it so hard? Any way, another nice example of natural mapping, that I have encountered on a Mac is, you see the Caps lock light located on the button itself. Sweet, no more searching!

Knowledge in the head versus knowledge in the world: This concept is complementary to the natural mapping one. If you make use of natural mapping, like having a switch board that mirrors the physical layout of the room, it reduces the burden on the person to hold the knowledge in the head of what switch does what. On the contrary, you are putting that information out in the world! A great benefit of this is reduced learning curve for everybody, when dealing with new switches.

Visibility: When designing systems, sometimes people get too caught with aesthetics and don’t care much about usability. You might have come across numerous faucets or doors that look awesome but are not very friendly to operate. Every time I see one of these new faucets, I spend at least a minute or two trying to figure out how to make it work. I once rented a car for which I could not figure out for a long time how to lower the windows. I approached a toll booth and I actually had to get off of the car to pay the toll. Funny! Later I figured out there was a small knob above the radio to lower the windows. Who thought it would be a good idea to put the window opener on the dashboard. Another funny incident that happened to me on the British Rail train, which I think the author mentions too in the book. The train stopped at my destination station and I was waiting patiently for the doors to open automatically, as there was no handle on the door to open it. Somebody walked from behind me, lowered the window on the door, put his hand out and turned the handle on the outside to open the door. Holy cow! Had I not known about that, I would have easily missed my stop. Coming to the point of visibility, the author argues it is extremely important to provide visual clues, to help the user, to operate the system. A long hanging chain with a handle at the bottom provides a visual clue that the device can be operated by pulling it. Sure aesthetics are important, but usability comes foremost. And by the way, I don’t think the British Rail train door was designed that way for aesthetic purpose.

While I was reading this book, I had my own moment of slight ingenuity. I was thinking about how I have had a hard time opening cabinet doors that have a flat plate on the corner that needs to be pushed and then some spring is released and the door pops out. I always try to put my finger in the small gap between the door and the cabinet and pull it out. I thought it might be nice if you could make a small depression on the plate, big enough the size of a finger, to indicate that the plate needs to be pushed to open the door.

Feedback: The author talks about how important it is for the system to give the user feedback, for the action they have performed, to assure that they have completed the task successfully. You do not want people sitting there thinking the machine is doing something when it is doing nothing or even vice versa. Feedback can be provided by sound (buzz when the microwave door opens), lights (caps lock is on), tactile (pressing a button on a telephone), et al. These are examples of feedback provided after an action has been performed. One of the examples that the author gives, is for providing feedback, even before an action is performed. This is about designing aircraft switches for landing gear and wing control, which I thought was ingenious given the risk involved in flying an airplane. He suggests that we create the landing gear switch shaped like a tire, whereas the switch that operates the wings shaped like a flat plate. When the pilot is working with these switches, the tactile feedback of touching a flat plate versus a round knob would have a much bigger chance of reducing error as opposed to having both the switches feel the same, especially in pressure situations.

Constraints and forcing functions: Constraints can be used very effectively to better design products. For example, keys for locks are designed in such a way that it goes in only one way, which is a constraint that is built into the system to avoid making errors. Computer programs do this well these days with disabling certain options on the screen when they are not applicable to the user. Washing machines do not let you open the door when the system is running to avoid possible mishap. The author talks about other types of constraints like cultural constraints. An example of this would be when creating a LEGO model of motorcycle driver, the user knows to build the model with the motorcycle driver facing forward because it is the only possible way the driver can drive safely. The author issues a word of caution in using constraints because sometimes they can be a source of annoyance. You would know what I am talking about, if you have been in a situation where you are carrying stuff in your car and you place a heavy bag on the passengers seat and the seat belt buzzer goes off when you start driving the car. It would be dangerous if the driver permanently disabled the passenger seat belt warning. What I have seen happen is that the seat belt warning beeps for a while and then displays a warning on the dashboard to indicate the non-compliance, which is not so annoying.

So what do I think of the book? I think it is great. It is very insightful. I got a little lost in the middle where it starts to talk a lot about psychology but there was always something that piqued my interest. The other thing I liked about the book is the book itself. Its nice and concise with 200 odd pages. I think books with about that size are perfect. They are easy to carry around, not too long yet enough to give a good understanding of about anything in the universe.

When I first started reading the book, I thought all these issues were minor, trivial or first-world problems¹. Then as I started thinking more about it, I realized how important the problem is of fixing the usability of everyday things like train doors, aircraft switches, car windows, gas burner switches, et al. The problem only gets worse when you think of operating these devices in a panic situation. We have been producing fantastic devices until now but not paying a lot of attention to usability and I think that should be one of our top priorities going forward.

[1] First-world problem

My first response to any such calculation intensive activity is to push it offline, to avoid the runtime calculation penalty. But in this case, the calculation involved inputs from the user and hence did not lend itself very well to pre-processing. We could have done something that a Oracle cube does, where it builds aggregates of fact data before hand, to expedite the processing time required. But in our case, pre-processing the results for all the possible user input options would have been extremely wasteful in terms of storage. The other concern with this approach would be that, there would be some time delay between the data being available and being usable, due to the pre-processing.

Then came the suggestion of manipulating the data in stored procedure. It made me shudder! Having recently read Pramod Sadalage’s blog¹ on pain points of stored procedures, I certainly was not in a mood to accept this solution. The pain points outlined in the blog that particularly appealed to me were, no modern IDE’s to support refactoring, requiring a database to compile a stored procedure, immaturity of the unit testing frameworks, and vertical scaling being the only option to scale a database engine.

As we all know, Ruby is perceived to be slow and incompetent to perform any computationally intensive tasks, and consequentially was not an option on the table. I thought to myself, Ruby can’t be that slow. The calculation we were doing was non-trivial but not super involved either. I decided to give it a shot.

We started by doing all these calculations using ActiveRecord objects and found that the performance was not good at all. ActiveRecord was the culprit because it was creating all these objects in memory and considerably slowing down the calculation process. We ditched it and opted for straight SQL instead and storing the results in arrays and performing the calculations on those arrays. Better! But not good enough. We found that we were performing operations like finding max, min, order by for a given column values in Ruby and which wasn’t particularly performant. We delegated those to the database engine, since they are typically good at such things and saw quite a hefty performance gain. By doing these simple tricks, we could pretty much get the performance that we were looking for.

Even though we had solved the performance problem, we had an unintended side-effect of our design. Given that we were processing data in arrays and outside of the objects where they were fetched from, the code looked very procedural. To solve this problem, we created some meaningful abstractions to hold the data and operate on it. These weren’t at the same granularity as the ActiveRecord would have created in the first place, but at a much higher level. This way it was a good compromise between, having too many objects and procedural code on the other hand, yet getting the performance we desired.

The biggest win for me in doing all these calculations in Ruby, was keeping the business logic in one place, in the app, and unit testing exhaustively the calculation logic.

I guess none of this is revolutionary in any way, but I guess next time I face a similar situation, I would have the conviction that, Ruby is not all that slow.

¹ With so much pain, why are stored procedures used so much

We have had numerous heart burns in the past over, not being able to successfully integrate with external systems, leading to delays and frustrations. Examples of integration points in a typical software system could be web services, databases, dropping files via FTP into obscure locations, GUI. Number one reason for our failure to integrate, has been our lack of ability to fully understand, firstly, the complexity of the data being transferred across the boundary and secondly, the medium of transfer itself. We think we understand these 2 things and then proceed with the development with mostly the sunny-day scenario in mind. We happily work on the story development until we hit this integration boundary and then realize, damn, why is this thing working differently than we expected. Not completely different from what we thought, but different enough to warrant a redesign of our system and/or having to renegotiate some integration contract. By then we have spent a lot of time working on things which are very much under our control and could have been done later.

Now what are the possibilities that we could not have potentially thought about in the first place? Let me start with a real-world example that I have come across. We were integrating with a third party vendor that delivered us some data via XML files. We had to ingest these files, translate them to HTML and display on the screen. Easy enough? We thought so too. We got a sample file from them, made sure we were parsing the XML using the schema provided and translating it into HTML that made sense for us. We were pretty good at exception handling and making sure that we did not ingest bad data. The problem started when we were handed a file of over 10 MB of data. Parsing such a huge file at request time and displaying the data on the screen in a reasonable amount of time was impossible. At this point we were forced into rethinking our initial “just-in-time” parsing strategy. We moved a lot of processing offline, as in, pre-process all the XML in to HTML and store it in the database. This alone did not solve the problem, for it was still not possible to render the raw HTML on the screen in a reasonable amount of time, since the HTML had to be further processed to be displayed correctly with all the styling. Obviously the solution was to cache the rendered HTML in memcached. We hit another road block with memcached, being unable to store items greater than 1 MB in size. Surely, we could have used gzip memcached store or some other caching library but that wouldn’t have solved our problem either. We chose to create another cache store in the database. After doing all this, some of the pages were still taking too long to load because of the sheer size and as a result, the business had to compromise on not showing those pages as links at all. But this meant that we had to know the page sizes before hand, to determine where to show links and where not to. All this led to a lot of back and forth, which is fine, but had we known about this size issue earlier, it would have saved us a lot of cycles. By the way, we could have incrementally loaded the page using Ajax but it was too late and wasn’t trivial for our use case. We could have known about the size issue if we had integrated first and worked with a realistic data set rather than a sample file.

So as per the example above, our integration point dictated our architecture in a huge way and also, more importantly, business functionality which is another reason to practice integration-first development. In an ideal world, you would like to insulate yourself from all the idiosyncrasies of your integration points but it rarely happens in a real world.

Other issues around integration points that have influenced our design are, web services going down often, and hence having to code defensively by caching the previous response from the service and setting the appropriate expiration time on it based on the time sensitivity of the data. In some cases, you might want to raise an alarm if the service goes down. If you know that it happens too often, then you might want to have it raised less frequently and be more intelligent about it.

There have been cases, when we have had no test environment to test a service and hence having to test with the production version of the service, which could be potentially dangerous. We had to do it in such a way, so as to not expose our test data in production. This meant our response had to change based on what environment they were being sent from. Certain services charged us a fee per request hence we had to reduce the number of service calls to be more economical.

Some vendors offered data via database replication and occasionally sent us bad data. In this case, we had a blue-green database setup where we had two identical databases, blue and green. The production would point to one of them, say it was pointing to blue. We would load the new data in the green database, run some sanity tests on the new data and only when the tests pass, point production to green. We would then update blue to keep it in sync.

Some of the vendors offered data via flat files. Sometimes they would not send us files on time or completely skip them. We updated our UI to reflect the latest updated time so as to be transparent. In addition to the file size episode I mentioned above, we had another problem with large file sizes. Our process would blow up when we processed large amounts of data. It was because we were saving large amounts of data to the database in one go, which wasn’t apparent initially.

Performance of external systems was an issue and obviously affected the performance of our app. We had to stress/load test the external system before hand and build the right checks into the system if the system would not function as expected.

We have tried to mitigate these integration risks in a number of ways. We implement a technical spike before integrating with an external system, to understand its interactions or even feasibility in some cases. When integrating with data focused stories, what I have found to be most useful is, as a first step, striving to get all the (minimum releasable) dataset into the system, without even worrying slightly about UI* jazz. Don’t bother the developers with UI since it can be distracting. Have the raw data displayed on the screen and then “progressively enhance” it by adding sorting, searching, pagination, etc. This is popular concept used in UI view rendering where you load the most significant bits of the page first and then add layers of UI (javascript, CSS) to spruce it up so that the user can get maximum value first.

On a recent refactoring exercise, we moved a tiny sliver to our application to a new architecture to test out fully the integration points and have a working model first. After that it was all about migrating other functionality to the new architecture.

There are so many things that could possibly go wrong when integrating and it is always a good idea to iron out the good and bad scenarios, before you start working on anything that you know you have full control over. I am not saying you could predict all these cases before hand, but if you start integrating first you have a much better chance of coming up with a better design and delivering the functionality in a reasonable time.

I would like to leave with you two thoughts: integrate-first and test with real data.

* UI can have exacting requirements too, in which case it should be looked at along with data requirements. Some UI requirements that could influence your architecture are loading data in certain amount of time or in a certain way, like all data should be available on page load.

Lets start with a quick example of the two application types: desktop and web. An example of the web application would be the ubiquitous shopping website where the user interacts with the website via a browser. An example of desktop application would be a thick client for trading stocks or even a rich client-side UI interaction in a web application using Javascript. When contrasting between web application MVC and desktop application MVC, I would be considering purely the HTTP/network communication aspect in a web application for MVC, devoid of the Javascript, Ajax or client-side templating.

To talk a bit about the architecture, the basic components of the two styles are the same: Model, View, Controller and hence the name. Sparing the details of the pattern itself, a subtle yet important difference between the two styles of MVC is that, for a desktop application all 3 components live in the same memory space on the same machine and this has some significant implications which we will talk about later. For a web application though, the controller and model live in the server memory space but the view partly lives on the server and partly on the client. The view is built on the server but interacted with on the client (through the browser).

Coming to the control flow, in a desktop application, the user interacts with the view to generate events. These events will be intercepted by a controller action which uses the model to update/retrieve data. There are multiple ways in which the view will be updated to reflect the model state change. Either the controller will directly update the view, or by employing the observer pattern. In the observer pattern, all the components interested in the model change, will register with the model. When the model changes, it informs all the observers of the change. This is the interesting bit of communication that you do not get to see in a web application. Since all 3 components, M,V and C, are objects in the same memory space, the communication between them is richer, hence a model can notify all the interested models/views about its changes. Another interesting pattern of communication is, the direct communication between the view and model on a user event. Given that the controller has bound the correct model action to a view event as a callback, the view can directly invoke the model action on the trigger of the event. Lets put this in perspective with an example. In the desktop trading application, lets say the user has the ability to change the trading currency. This currency is being used for transactions in multiple widgets/views on the same page. In MVC land, this currency change event is tied to some update action on the trading currency model. When the user changes the currency, the model is updated directly. The model then notifies all the registered observers (predominantly models) about the currency change who then subsequently update their respective views. This communication seems very natural in a desktop style MVC.

Lets look at the web application control flow. The user interacts with the view via the browser. The view is built on the server with 2 pieces of information: one, the actual view code and second, a mapping of user event to a controller action. Each user action is converted into an HTTP request by the browser. On the server side, the web application framework invokes the controller action. The controller action uses the model to retrieve/update data, builds the next view and sends it back to the browser as a HTTP response. The browser renders the view code and then the user is free to interact with the view again. In this style of communication, all the communication between the view and model has to be channeled through the controller. Going back to our example of updating trading currency, in a web application, updating the currency would mean having a currency update controller action that updates the necessary models and then builds the entire page with updates to all the necessary views and retaining the unchanged views. This seems like inelegant approach as opposed to the desktop style of MVC.

The web application seems fit for one-page-one-user-event model where you put all the information on the page, post it to the server and get back some results. It makes the web application single-tasked and slow to respond to user events. But life is rarely simple enough to warrant a single threaded communication, especially in the world of fancy UI interactions. True to the saying, “a layer of indirection can solve every problem in computer science”, it seems Javascript can solve some of these problems. It provides the rich user interaction to a web application and fetch and update selective parts of the view using Ajax and client-side templating. It is still a pull mechanism where the Javascript is pulling all the necessary information and updating the relevant bits as opposed to a desktop application where you could update the model and then it publishes its changes to interested components who update themselves as they see fit.

I would classify refactoring into 3 levels ordered by increasing scope, and consequentially, effort.

1) class level refactoring

This is the type of refactoring typically done at the end of red-green-refactor cycle. As TDD practitioners are aware, you write a failing test for the business expectation, you fix the test and then refactor the code to make it ‘better’. Here are some examples:
a) rename methods/variables to clearly express their intent
b) extract duplicate lines of code into a method
c) memoize to avoid duplicate calls to expensive pieces of code
d) write idiomatic code. I was baffled when I first heard the word ‘idiomatic’ so let me take a minute to explain it. It means using the language constructs rather than the plain old constructs, that you find in almost every language. An example in Ruby would be: lets say you have a method that initializes an array, adds some elements to the array and returns the array. As you can imagine, these three steps would each correspond to a line in your method if written in a non-idiomatic fashion. If you were to write idiomatic code, you would use tap instead. Here is how it looks.

[].tap do |fruits|
  fruits << 'apple'
  fruits << 'banana'
end

2) story level refactoring

This is the type of refactoring, you do when the story is “functionally” complete. Here are some examples:

a) convert procedural code into object oriented code. A symptom of procedural code is, manipulating the state of an object outside its own class. Here is an example:

if(input.numeric?)
  NumberFormatter.format(input)
else if(input.date?)
  DateFormatter.format(input)
end

In this case, some code outside the input class is making a decision of which formatter to apply to a input. This clearly breaks encapsulation by exposing the input data to something outside the input class. Doing this the right way would mean, when initializing the object you create the right type of class based on its input, like a NumericInput vs DateInput, write a format method on each of those classes and simply have the client call the format method on the instance of the class. The client should not care what instance it is calling the format method on, as long as the input type knows how to format itself.

Here is how it looks:

class NumericInput
  def format
  end
end

class DateInput
  def format
  end
end

client code would be:

input.format

Believe it or not, a lot of your decision making statements will go away, if you create the right type of objects. To create the right type of objects, it is very important to identify the right abstractions for “state holders” and then push the behavior on to those abstractions(classes in object-oriented world).

b) Remove duplicate code from multiple classes and create common abstractions.

c) Watch out for performance-related refactorings like avoiding n+1 query problem, removing/merging duplicate database/service calls, caching expensive service/database calls, avoiding fetching more data than necessary from external services (example being fetching all the search results and counting them as opposed to directly getting count of results or getting database results and sorting the results as opposed to fetching sorted results), graceful handling of service/database error conditions.

3) big bang refactoring

This is the type of refactoring where you change a large part of your code, purely for technical reasons. The drivers for this type of refactoring are the exorbitant cost of changing a relatively small piece of code, performance being unacceptable, the code being too buggy and rather be rewritten than applying band-aid solutions or the code breaking in production and it is hard to tell what is going on. The effort is too big to be handled as a part of a ‘feature’ story and hence has to be done independently as one or more stories.

Big bang refactoring stories are generally hard to sell because they don’t deliver any client-facing functionality, the impact and to some extent the scope being unclear(example being refactoring Javascript code for a page to follow MVC pattern) and the fear of breaking something already working. These stories have to be drafted with a clear end goal in mind to give the developers a good idea of the scope and assess the impact. The story should enunciate the pain points being addressed as a part of acceptance criteria and the rough amount of effort required. Such stories should be more actively monitored to avoid losing focus. The stories with high level of pain and low level of effort should be prioritized first. It is possible that such stories might never get prioritized. In such a scenario, the work should be broken down into smaller chunks and handled as type 2 story-level refactoring with a related feature card.

Lessons learnt:

* Make separate unit tests for testing different intentions of a method. For an example, lets say a method returns a hash of attributes about a person object. So you would have a separate test for each item in the hash or at least a logical grouping of items in the hash. Here is an example

it "should format the name" do
  person.to_hash[:name].should == 'Todkar, Praful'
end

it "should calculate the age based on the birth date" do
  person.to_hash[:age].should == '29'
end

This way it makes it easier to understand the behavior being tested. Also if some of the logic changes or goes away it is easy to change or delete the test. Also, you could test the complicated parts more rigorously without testing everything that the method returns. You could put the test setup for the method in a before block to avoid duplication.

* Avoid unit testing of private methods of a class. Testing private methods is a smell and indicates that there is too much going on in the class being tested. The fact that you want to test the private method without going through the public interface means that you could easily create an abstraction for that code and inject it as a dependency. You could test the dependency separately and rigorously. For example, there is a method that finds the median age for a group of people stored in a database. Now as you can see, there are two separate pieces of logic here. The part where you read from the database is fairly easy to test where as testing the median age is more complicated and hence can be tested easily and thoroughly if it were its own abstraction. Also for some reason if your logic changed to find the mean age instead of the median age, your database test should remain the same.

* Try to do as much unit-level testing as possible to isolate problems during test failures. The other advantage of unit testing is that it helps reduce the combinations of integration/functional tests. Say you have to write a functional test to test a form that accepts age as one of it fields. If you have properly unit tested all the edge cases for the field accepting age as an input, then the form submission test does not have to deal with various combinations of age input. Almost always integration tests are an order of magnitude slower than unit tests. Unit tests give you faster feedback at relatively low cost.

* It is very important to have clearly defined outcomes for refactoring stories. I was on a project that had the first phase of the project dedicated to refactoring. Quickly we realized, we weren’t making much progress as it was hard to tell when a refactoring story was done. The boundary lines of the refactoring stories were blurry, hence causing confusion. I recommended that we tie refactoring effort to new feature stories, originally planned to be developed in phase 2. The approach we took was refactoring code in and around the feature we were working on. This way we had a better sense of story boundary and knew when to stop refactoring. Once the patterns were in place, it was easy to replicate those across the code base. The business also liked it as they started seeing features delivered sooner than they had anticipated.

* If you find too much mocking/stubbing of dependencies when testing a method in a class, it might be a good time to consolidate the dependencies into fewer abstractions, and delegate some of the testing to the new abstractions. Too much mocking/stubbing can be a result of a chatty interaction between multiple dependencies. It happens when you have data being passed around from one object to the other. It helps to have a owner of the data and push the behavior on to the data owner to avoid chatty interaction.

* One of the tips that I have found useful when naming classes is having the name be a noun as opposed to a verb. For example, when picking a name for a class that compares hotels, it should be called HotelComparison as opposed to HotelComparer since it feels more natural for a HotelComparison class to hold state like date of comparison, result of the comparison, requesting user. This helps in writing more object-oriented code.

* Always test the public interface. One of the biggest advantages is that unit tests don’t break when internal implementation changes. Also it strengthens the idea of having a public interface for a class.

* Functional/UI tests can be very useful when doing story level or big bang refactoring to make sure that the functionality is working as expected.

* When refactoring a large piece of code, change one thing at a time. When refactoring a complicated piece of Javascript code, we decided not to change the structure of HTML, so that we do not break the CSS and keep it out of the equation.

* When refactoring a large piece of code, follow a top-down refactoring approach. Make sure that you create the right abstractions first and establish the interactions between them in such a way that data lives as close as possible to the class manipulating it. Then move on to refactoring individual classes. If unit tests exist, it is easier to ignore them until you have stabilized on the classes and their methods.

Q: Who should be involved in an estimation session?
A: Primarily the developers and business/product owners. If the stories are UI intensive, it is always a good idea to involve the UX owners too. People with purely managerial responsibilities should not be present, as it could put pressure on the developers to throw lower estimates.

Q: Should all developers on the team participate in the estimation session?
A: Yes, everyone should be present at estimation for a decent sized team (3-4 pairs). An anti-pattern would be to pick people, who have worked or have the most context on the story to be estimated contributing to siloing of information. Having everyone present, helps the team to realize if the knowledge is not being shared around enough. Also if people who have no context, end up working on the story, it could lead to a bad estimate. Estimation requires the developers to throw a number and hence keeps them fully engaged and leads to better understanding of the story and the application as a whole. Estimation is also a time to spread awareness about technical debt surrounding the story. It is also a quick way to get acquainted with unknown parts of the application and the system/technical landscape. Certain implementation decisions are also made/communicated at estimation time.

Q: Should stories be completely fleshed out before estimation?
A: They should be fleshed out so as to give the developers enough context to estimate the level of effort. Having product/business owners at the estimation helps to answer questions or concerns that the developers have during estimation. Better story narratives lead to better estimates and better assumptions.

Q: Should stories be time-boxed?
A: Absolutely, time boxing of stories is very important. Developers tend to discuss technical issues in detail during estimation. This is ok if the story is straight-forward but if the discussion goes on for too long it is a waste of everyone’s valuable time: developers and the business. A rough guideline would be to limit the story discussion to 8 minutes. The business/product owner starts by explaining the business case for the story and the scope. At the end of the time limit, if the developers feel they do not have enough information to estimate the story, the discussion should continue for another minute. If the story still cannot be estimated, it could be because the team does not understand the business domain well enough or there are technical concerns. If it is the earlier case, then separate workshops could be held for the developers by the business to provide an overview of the business domain. If there are technical issues, then the team should decide on 2 possible options: one, a pair should do tech analysis for the story or do technical spike and then estimate it at the next estimation session. Tech analysis is where a pair of developers attempt to answer all the outstanding questions, technical or business related. This may involve coming up with a technical solution, analyzing external dependencies like data ingestion, database schema creation, services, etc. Technical spike goes one step further and involves writing code to prove technical feasibility of the solution, when using new technologies or to understand the performance implications of the solution. It is important the pair records the outcome of the analysis or spike on the card itself, for it to be referred to, at the next estimation session. The 8 minute time limit generally works for most stories, but it could be adjusted based on the team feedback.

Q: Should every story be tech analyzed before it is estimated?
A: If you notice a trend that every story ends up being a long technical discussion or exceeding the time limit, then it makes sense to do it before hand so as to save everyone’s time.

Q: Where should estimation assumptions be captured?
A: Estimation assumptions should be explicitly noted on the story card. A change in story assumptions can potentially lead to re-estimation of the story. Story assumptions include notes about external dependencies and significant technical implementation details like system should display real-time data as opposed to cached.

Q: Should technical debt surrounding a story be factored into the estimate?
A: Yes, it should be. In fact, it is the best possible way to tackle technical debt on the project. Two arguments can be made in favor of it: the code in that area will be touched, might as well make it better. Second, it would make it easy to build on top of the code in the future. The extent of technical debt should be investigated by doing some tech analysis. The outcome of the tech analysis should be the scope of the technical debt that would be dealt with, as a part of the story. This can be a slippery slope and care should be taken to not add too much technical scope outside the realms of the story in consideration.

Q: Should testing efforts be included in the estimate of a story?
A: For run-of-the-mill stories, the estimate should not account for the testing efforts, be it manual/QA testing or automated testing done by developers. There should be a testing strategy in place and all the stories should more or less follow those patterns so that the estimates are evened out for an iteration. If new testing strategy gets introduced that negatively affects the velocity, then appropriate expectations should be set with the team and management rather than polluting the estimates. But for stories that require an exceptional amount of testing effort, it should be factored in.

Q: Should stories be ever re-estimated?
A: Stories should be re-estimated only in exceptional cases like changes in team, architecture, scope and assumptions.

Q: Should different versions of the story be estimated? Different UI look and feel? different implementations – service vs local database?
A: This is a tricky one. One one hand, it gives the business/UX a great feedback on the different options and the associated cost. But it can also be a source of confusion and a potential waste of valuable developer time. If this happens too often, then the business needs to be made aware of the time spent on the estimation, and if it is worth it. One way to tackle this could be to estimate different variants separately and then add them up to get a feel for the effort. But in the end, the story should be estimated holistically.

Q: Should bugs be estimated?
A: Bugs should not be estimated, since they are misunderstood/unfulfilled expectations whose effort have already been accounted for. They should be given the smallest possible estimate to account for the time spent analyzing the root cause and not necessarily the time to fix it.

Q: Should chores/tech debt be estimated?
A: Chore cards or Tech Debt cards should be absolutely estimated. Making them go through a rigorous estimation process helps the primary beneficiary enunciate clearly the requirements and also an idea of, if the cost is worth the effort.

Q: Should stories be broken down during estimation?
A: Yes, if it makes sense. Smaller stories are much easier to be developed and tested. There is a business tendency to lump stories together since they wish to deliver the entire chunk of work in the same iteration but the counter argument could be that since stories have been broken into pieces they could be played in parallel. If the story gets broken down, the story should not be estimated until the story is completely fleshed out.

Q: How early or late should estimation be done before a story gets played?
A: The estimation should be done typically an iteration or two before the scheduled iteration. Things change fast on Agile teams so if stories are estimated too much in advance, there is a possibility they might have to be re-estimated. Doing it just in time means people on the team have the context fresh in their heads when the story is played. Doing it before the iteration starts, gives the business an opportunity to not play a story if they feel the benefit is not worth the effort.

Q: How often should the estimation sessions be held in an iteration? Should there be ad hoc estimation sessions?
A: The estimation sessions should be held twice every iteration on specific days of the week, typically right after lunch. This sets a natural rhythm for the team and also the discipline of doing tech analysis is rigorously followed the day before or the morning of the estimation. Ad hoc estimation sessions should be avoided and should be held only under exceptional circumstances since any kind of meeting disrupts the rhythm of the team.

Q: How many stories should be estimated before an iteration begins?
A: More than what could possibly fit in an iteration. Firstly, it gives the business an opportunity to adjust the scheduling of a story based on the estimate and secondly if the team runs out of stories mid-iteration, there are buffer stories. If a story does not get played for a scheduled iteration, it could be played in a later iteration provided not much has changed in terms of team, architecture, scope and assumptions.

Q: Can a story be changed after estimation?
A: Only in exceptional cases. If the changes do no affect the estimate(approved by team or team representative), it is ok, else the story should be re-estimated.

Q: Can estimates for a story be used for a different team?
A: Estimates are contextual and always unique to a team. They cannot be enforced upon a different team. The estimates are made by a certain group of people who have certain knowledge of the application and the code base.

To set some context, say you have built an application in Rails using Ruby 1.8.7 and is deployed on a UNIX system. Scaling the application means spawning multiple processes to serve client requests. Since memory cannot be shared between processes, there is whole lot of memory wasted in holding the same Rails code in multiple processes. Modern UNIX systems provide fork functionality which let a child process share memory with the parent. So essentially there would be one parent process holding the, shared by all memory, and it would spawn child processes, which will share the parent’s memory. When something is being written to the shared memory by the parent, each child process is given a copy of that memory and shared memory in the parent process is written with new data. Similarly, when the child writes to the shared memory, the child gets its own copy of that memory and writes to it with the new data. This is called copy-on-write (COW) technique.

Now lets see how the Ruby 1.8.7 garbage collector works. It is apparently simple in its implementation. It uses a mark-and-sweep algorithm to collect unused memory. What this essentially means is, it scans each and every object and marks a flag “on” the object currently being used. At the end of this cycle, it sweeps or collects all the objects that have not been marked. But the problem here is that the “mark” information is stored on the object itself, in essence making each used object “dirty” which triggers a copy-on-write by the underlying UNIX system. All the used objects held in the shared memory, will be copied to each child’s memory space. This nullifies all the memory savings that would have been possible with the copy-on-write technique. This is why Ruby 1.8.7 isn’t copy-on-write friendly.

Ruby Enterprise Edition circumvents this problem by patching the GC to store the “mark” information outside the object. For more information checkout this.

For a longer and better explanation, go here.