Archive

Posts Tagged ‘methodology’

Methodology Taxonomy

September 28, 2012 2 comments

Here’s a feeble attempt at sharing a taxonomy of well-known (to BD00) software development methodologies:

Got any others to add to revision 1? How about variations on the hated “WATERFALL!” class? Where should the sprawling RUP go? What about “Scrum-but“? Does “kanban” fit into this taxonomy, or is it simply a practice to be integrated within a methodology? What about “Lean“?

From Complexity To Simplicity

September 9, 2012 3 comments

As the graphic below shows, when a system evolves, it tends to accrue more complexity – especially man-made systems. Thus, I was surprised to discover that the Scrum product development framework seems to have evolved in the opposite direction over time – from complexity toward simplicity.

The 1995 Ken Schwaber Scrum Development Process paper describes Scrum as:

Scrum is a management, enhancement, and maintenance methodology for an existing system or production prototype.

However, The 2011 Scrum Guide introduces Scrum as:

Scrum is a framework for developing and sustaining complex products.

Thus, according to its founding fathers, Scrum has transformed from a “methodology” into a “framework“.

Even though most people would probably agree that the term “framework” connotes more generality than the term “methodology“, it’s arguable whether a framework is simpler than a methodology. Nevertheless, as the figure below shows, I think that this is indeed the case for Scrum.

In 1995,  Scrum was defined as having two bookend, waterfall-like, events: PSA and Closure. As you can see, the 2011 definition does not include these bookends. For good or bad, Scrum has become simpler by shedding its junk in the trunk, no?

The most reliable part in a system is the one that is not there; because it isn’t needed. (Middle management?)

I think, but am not sure, that the PSA event was truncated from the Scrum definition in order to discourage inefficient BDUF (Big Design Up Front) from dominating a project. I also think, but am not sure, that the Closure event was jettisoned from Scrum to dispel the myth that there is a “100% done” time-point for the class of  product developments Scrum targets. What do you think?

My Velocity

January 21, 2010 1 comment

The figure below shows some source code level metrics that I collected on my last C++ programming project. I only collected them because the process was low ceremony, simple, and unobtrusive. I ran the source code tree through an easy to use metrics tool on a daily basis. The plots in the figure show the sequential growth in:

  • The number of Source Lines Of Code (SLOC)
  • The number of classes
  • The number of class methods (functions)
  • The number of source code files

So Whoopee. I kept track of metrics during the 60 day construction phase of this project. The question is: “How can a graph like this help me improve my personal software development process?”.

The slope of the SLOC curve, which measured my velocity throughout the duration, doesn’t tell me anything my intution can’t deduce. For the first 30 days, my velocity was relatively constant as I coded, unit tested, and integrated my way toward the finished program. Whoopee. During the last 30 days, my velocity essentially went to zero as I ran end-to-end system tests (which were designed and documented before the construction phase, BTW) and refactored my way to the end game. Whoopee. Did I need a plot to tell me this?

I’ll assert that the pattern in the plot will be unspectacularly similar for each project I undertake in the future. Depending on the nature/complexity/size of the application functionality that will need to be implemented, only the “tilt” and the time length will be different. Nevertheless, I can foresee a historical collection of these graphs being used to predict better future cost estimates, but not being used much to help me improve my personal “process”.

What’s not represented in the graph is a metric that captures the first 60 days of problem analysis and high level design effort that I did during  the front end. OMG! Did I use the dreaded waterfall methodology? Shame on me.

%d bloggers like this: