Wednesday, May 25, 2011

Software Estimation - An Organic Approach

In previous posts I have described the extreme ends of the software estimating spectrum.  Neither end is desirable.  First, let me say that I don't like estimating, at least not the estimating that puts stress on developers to meet unrealistic time-lines.  I like the idea of continually delivering value to customers [Product Owners] based on business priority.  Trying to predict software delivery is risky business.  To mitigate that risk we as professionals adopt Agile beliefs and methodologies.  That is just not always possible.

If I have to estimate for waterfall SDLC, then I believe that good estimating is the result of weighing several factors, not the least of which is experience.  This is why junior developers generally do not make good estimators; they simply lack the requisite experience upon which to base their decisions.  However, if you must estimate, juniors should be included in estimation processes so that they can learn the skill.

If we reflect on the purpose of estimation, we realize that we are simply forecasting a future outcome, based on information available to us now.  The information at our disposal is a an amalgam of data, experience, technology knowledge, code familiarity, application familiarity, business process knowledge, etc.  The list goes on.  The secret sauce to estimating is how we apply these data, information, and knowledge to execute tasks to a prescribed standard.  Knowing what is relevant and what is not also helps in constructing a clear and accurate estimate that will stand up to scrutiny.  Finally, good estimators can articulate why they made certain decisions that led to the estimate.

Truly accurate software estimates start with truly accurate analysis.  That is to say that before a developer begins an estimate, he or she should understand (as much as possible) the functional and non-functional requirements of the work to be accomplished.  The degree to which the analysis is done [correctly] will directly contribute to estimate accuracy.  During the estimation process, developers match requirements to code artifacts and apply proper weighting based on complexity, etc.  Without a good understanding of the requirements, this step is not possible; moreover, estimators may apply a ambiguity factor to the overall estimate when requirements themselves are ambiguous.   This comes dangerously close to sand-bagging or artistry if not properly monitored by senior developers/estimators.

One of the important factors of accurately assessing and estimating work is understanding that one should reach out to his or her team for their input and support.  No one person on a software team knows everything about the task, or the software components (real or imagined) that are involved.  I like to start with the abstract approach of estimating stories and assigning story points that typical Scrum projects use.  I like to get my developers together and have them assign story points to each of our JIRA tickets that have been prioritized by the business.  Even if we are not full-blown Scrum and we do not have a defined "Product Owner" role, we still start with a list of business priorities. 

Once we know the list of prioritized JIRAs each developer picks a number from the Fibonacci sequence, starting at 1 and ending at 144 and assigns it to the JIRA, based on his or her knowledge of the task, code, application, experience, etc.  For this purpose there is no need to go any higher than 144, and using the Fibonacci sequence helps to eliminate the ambiguity of more linear scales, like 1-10 or 1-100.  This approach of assigning more abstract values to the initial estimate and using the input of multiple developers facilitates discussions among team members, about the estimates for each JIRA.  More often than not, the true nature of the work needed is discovered through the discussions and the correct Fibonacci number is finally assigned to the JIRA.  Of course we would take this even further if we were a Scrum shop, but that is not the case right now.

The key to getting the correct Fibonacci number is to ask the team to qualify there answers with what level of developer would be needed. This should fall out of the discussion when certain members of the team have different estimates.  I try to convince my team that we are estimating for intermediate to advanced developers.  This eliminates the need later to take into consideration the level of the developer assigned to the task.

In my next post I will show how the JIRA/Fibonacci number is used further in a PERT analysis for more Waterfall-like estimates.

Tuesday, May 24, 2011

Are you an upbeat artist or a sand bag engineer?

In my experience, many software developers do not know how to properly estimate a development task, regardless of how familiar they are with code streams, constituent technologies, or business processes.  We do not learn this in college, at least not in undergrad.  I place most developers into two categories, artists or sandbag engineers. 

The artists paint "rosey" pictures framed by hyper-positive and unrealistic delivery dates.  These developers mean well, and I would go as far as to say that they are actively trying to counteract the notion that all IT is slow.  However, the main problem is that these guys do not consider the nonproductive time that they have on a daily basis.  They do not consider activities that distract them from the estimated development task, including task switching to other development tasks.  In general, their estimates are nonscientific and based on their recall of previous experiences and anecdotal evidence.  In fact, these developers mostly do not realize that they "cherry-pick" the good experiences from the last development efforts and do not appropriately weigh the bad.

At the end of the day, artists have agreed upon, unrealistic deadlines that require herculean efforts to meet.  Sometimes they become temporary heroes to their managers or customers.  However, as I have said before, hero worship is not a long term, sustainable strategy.  And stories are legion of developers taking shortcuts when they ran out of delivery time.  Sooner or later the facade decays and these developers are exposed for the poor estimators they really are.  They are not bad people, just bad at estimating.

The sandbag engineers (a.k.a. sand-baggers) are not any better.  These developers pad their estimates from the beginning, regardless of the task size or complexity.  Some of them suffer from "Kirk/Scotty" syndrome.  They think that if they say it will take longer than it actually should, they will look good when they deliver way early.  This of course is a fallacy when examined by the astute manager.  Coming in way early is almost as bad is coming in way late.  The estimates are still wrong. 

Sandbagging is insidious.  It slowly undermines the trust and faith that managers and customers have in their developers.  There is nothing wrong with delivering early when the scope of a project is elaborated to the point of reduced effort.  However, more often than not, sandbagging is just a front-loaded risk mitigation strategy that is not grounded in scientific methodology or data.

In following posts, I will describe how I have performed estimation in the past, based on experience, scientific methods, and data.  It's certainly not a perfect process, but it places me on the spectrum between the artists and sand-baggers and my estimates are more accurate.

Center for Teaching Excellence - Institute on Teaching & Learning

Last week I attended a 5 day workshop at VCU's CTE (Center for Teaching Excellence).  To say that it was an enlightening experience would be understating its immediate impact on me.  The ideas and techniques discussed in our sessions and espoused by the guest speakers demonstrated to me that I have a lot to learn about teaching and I need to change the way that I am reaching and engaging students, or not reaching them, as the case may be.

Of particular interest to me are the techniques for formative assessment.  I now realize that my techniques for evaluation are mostly summative.  When teaching CIS topics I guess it is easier to employ summative techniques.  What I immediately realized that I was missing was the proper feedback from my students.  The summative evaluations provide no feedback beyond the measure of how well students memorize.  I need to know if I am reaching them and keeping them engaged beyond the typical 8-10 minute attention span.

Should I teach in the Fall I plan to utilize more active learning techniques with particular collaborative learning activities.  I plan to use "Minute Papers" and JiTT to provide the feedback needed to direct my class and my students' learning towards higher levels.  My goal is to introduce meta-cognitive sessions by the Fall 2011 or Spring 2012.

Friday, May 20, 2011

Richmond Java Users Group (RJUG) Meeting - 05/18/11

Wednesday night I attended an RJUG meeting.  I am on the steering community for this group, but I don't usually have the time to attend regular meetings.  However, this meeting covered topics that I really agreed with.  As an Enterprise/Application Architect, I have over time shifted my thinking to simpler design:  simpler to accomplish, simpler to maintain, and simpler to understand.

The meeting was sponsored by Ironworks.  The topic was Blending Best of Breed Technologies and focused on integrating several Open Source tools and technologies:  Core Spring and Spring MVC, Groovy, FreeMarker, Liferay, and Alfresco CMS.  The presenter, Dennis Sharpe, did a great job presenting an overview of the individual technologies from a high level.  However, the presentation really shined when he demonstrated and communicated the integration techniques for these tools and how they were using them in production.  Of particular interest was how they used Groovy to shift certain highly dynamic code to the Freemarker templates stored in the Alfresco CMS.  I will not attempt to recreate the meeting in this entry.  If Ironworks makes the slides available later, I will post a link.