I cannot believe how much our education system has changed. When I went to kindergarten, most of curriculum revolved around getting along with others (a lesson some will argue never took with me) and some basic verbal skills. I learned at my daughter’s kindergarten orientation that blocks and finger painting have been replaced by geography, math, science and civics.
I walked out of her kindergarten orientation concerned whether or not my daughter would be ready for school. As kids have a tendency to do, though, my little girl came home on her first day and happily said her favorite part of the day was “voca-libraries” (actually, she said the bus ride, but this was her favorite part actually at school), which I determined was “vocabulary” after she said it was all about learning the meaning of words.
While her vocabulary list was understandably simplistic, it reminded me of a recent article by Ben Harden over at DZone’s Agile Zone that provided a vocabulary for agile development. The list included what seemed like a good introductory vocabulary for agile but for one glaring omission…
What Harden does define, he does well; all the other basics were there – agile, scrum, sprint and backlogs (both product and sprint) – are accurately and appropriately put into introductory language. Even I feel more comfortable with these terms after having read his list.
But for a process of development that all too often takes hits for not adhering to standards of application software quality, one would think that the term “structural quality” should somehow be included in a vocabulary list for those just starting with agile. (One side note to Ben Harden, usually vocabulary lists are in alphabetical order, so at first I thought maybe I had been the one who missed “structural quality” or any variation of it on this list.)
After all, the main reputation that agile development has is one of speedy development – get it done in parts means you get it done fast. Those who are doing the development, each on their own basis, undoubtedly take a certain sense of pride in building product. As I pointed out in a previous blog, though, those who participate in the scrums of an agile-developed product often find themselves pressured by the “business” types to “just get it done.” This carries with it the connotation that agile developers push software out the door without concern for its quality.
It does not come as a big surprise that the folks on the business side of software development do not understand the need for agile to focus on quality, but it should. When structural quality suffers, the final product suffers. The outages, security breaches and general unreliability of application software result in a major hit to the finances and reputation of a company. When you then add in the time it takes an IT department to fix the problem (i.e., technical debt), there is very little advantage to “just getting it done.”
So with all due respect to Mr. Harden, I believe a vital addition to the agile vocabulary list he offers is this:
Structural Quality: Architecture, compliance with architectural controls and interactions between application components, the failures of which cause 30% of major production defects that can result in deeply-hidden problems that pass functional and non-functional tests, but will inevitably cause application software to erupt in production and lead to lower productivity, high costs/TCO and more risk for business operations.