frameworks | Bulldozer00's Blog

From Complexity To Simplicity

September 9, 2012 bulldozer00 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?

Scrum Cheat Sheet (bulldozer00.com)
Ultimately And Unsurprisingly (bulldozer00.com)
Introduction to scrum (slideshare.net)
Scrum Master, a management position? (scrumguru.wordpress.com)
Developing, and succeeding, with Scrum (techworld.com.au)

Categories: technical Tags: Big Design Up Front, complexity, frameworks, Ken Schwaber, linkedin, methodology, product development, Scrum, software development

To Call, Or To Be Called. THAT Is The Question.

August 30, 2010 bulldozer00 Leave a comment

Except for GUIs, I prefer not to use frameworks for application software development. I simply don’t like to be the controllee. I like to be the controller; to be on top so to speak. I don’t like to be called; I’d rather call.

The UML figure below shows a simple class diagram and sequence diagram pair that illustrate how a typical framework and an application interact. On initialization, your code has to install a bunch of CallBack (CB) functions or objects into the framework. After initialization, your code then waits to be called by the framework with information on Events (E) that you’re interested in processing. You’re code is subservient to the Framework Gods.

After object oriented inheritance and programming by difference, frameworks were supposed to be the next silver bullet in software reuse. Well crafted, niche-based frameworks have their place of course, but they’re not the rage they once were in the 90s. A problem with frameworks, especially homegrown ones, is that in order to be all things to all people, they are often bloated beyond recognition and require steep learning curves. They also often place too much constraint on application developers while at the same time not providing necessary low level functionality that the application developer ends up having to write him/herself. Finding out what you can and can’t do under the “inverted control” structure of a framework is often an exercise in frustration. On the other hand, a framework imposes order and consistency across the set of applications written to conform to it’s operating rules; a boon to keeping maintenance costs down.

The alternative to a framework is a set of interrelated, but not too closely coupled, application domain libraries that the programmer (that’s you and me) can choose from. The UML class and sequence diagram pair below shows how application code interacts with a set of needed and wanted support libraries. Notice who’s on top.

How about you? Do you like to be on top? What has been your experience working with non-GUI application frameworks? How about system-wide frameworks like CORBA or J2EE?