On Quality: Quick and Perfect! - V

At that point of our discussion on software quality as an attempt to deliver quasi-perfect products, I think that by now I’ve passed a sanity check for  what I advocate to be The Principle of Economic Perfection, which indicates that the promise to produce quasi-perfect software is possible, and economic,  if we own the competence and the Readiness for it. In this installment, we delve together into Readiness, explaining what it means, then articulating its pillars  that make it a fact supporting the uniqueness of the development organization.

So what’s Readiness in software?

In a nutshell, it’s the bridge between perfection and economy represented by a proactive development school of thought that enables a development team to reduce the development cycle to minimum time at maximum quality. In fact 80% of our projects, are covering a set of business applications that have become almost known to us all. So, there is no wisdom at all to call a project “totally new” as far as requirements and techniques are concerned,  except in the remaining minority of 20% of what we see. There is no need, whatsoever, to reinvent the wheel, as the adage says.

So how can we build that Readiness, to be able to pierce through  projects based on our previous knowledge and successes. Here are the means, which I call the Three Pillars of Software Readiness

The first pillar of Readiness, and maybe its magic mantra, is Reusability. I’ve no doubt that no one reading this is not, by age and/or experience,  belonging to the era of objectivity in software, so the word Reusability is well taken as the most rewarding attribute of the product of development to the developers. The biggest pitfall however for a great many of development shops is that they lose sight to it as they delve rushingly  into new projects under those sometimes insanely tight schedules. This is the bad side of the story. The good side is that they all  know the tools and features already inherent in the OOL’s for producing reusable code. The whole breed of “Classed” languages can deal with “design” ideas not just coding constructs. Concepts of Objectivity, mainly Abstraction, Inheritance, Polymorphism, Encapsulation are all deign pillars that are implemented also in programming languages, mainly to enhance the reusability of “clean” code that we write and test.

The conclusion: Think objectively in design and coding, most of us have the knowhow to do it, yet under time pressures we act like as if we are using procedural languages of the past. If you need to retrain on true OOPS’s features, just do it and make sure that ROI is huge. Let me re-emphasize: No development is truly object-oriented until it produces something Reusable.

The second pillar of Readiness is Patternization. There are three levels of Patternization that I’d like to touch:

  • Design Patterns: Here is one of the most helpful but forgotten topics, even in education, in the OOS arena. Since the Gang of Four (GoF)  have produced their seminal work Design Patterns some199x,  the topic was not much seen in labs or factories outside the circles of the software elite. Over the last decade, I’ve interviewed many developers and challenged their acquaintance with the  subject with much less than satisfactory results. In my opinion, this topic, in theory and practice, must receive far more investment to teach and use. Software people must be able to:
    •   Understand, use and even adapt design patterns to solve their own problems, and
    •   Produce their own design patterns for solving their unique problems as they evolve.
  •  Requirements Patterns: It’s not only  design that can be patternized. Requirements of similar clientele or industries can be patternized too. The pattern here is  nothing more than what people in, say, food industry usually look for. Or what would interest people in communications services marketing to have in any software solutions to their common tasks. The patternization of that kind is not only to include the user stories, but it may exceed that to some common business process(s)  for the industry, and even the lingo or the jargon of the craft!
  • Coding Patterns: that includes anything from styling and naming conventions up to complete well tested API’s. The theme is to  eliminate possibility of recoding the same algorithm or behavior more than once.

The Third Pillar is what I call Testology. The word may sound weird, I just conjoined “Test” and “Methodology” into it.  There is much to say here, but for the sake of our Readiness talk, suffice it to say that I’ve participated in trials in which the coding was driven by testing, not the opposite. A total new wave in agile development is advocating the TDD (Test Driven Development). What I’ve seen myself to be the real benefit is an arsenal of client code twinning every solution. This client code documents the design in one way or another, but most importantly eases out the burdens of change in the implementation, when it happens. My advice here is learn about  TDD and get at least a lab to test it on one real example. This is a smart way to adapt to change, be that in patterns or in actual systems.

I know, it may look like a hell of an effort to get the three pillars well established at one time. But I’m pretty sure that you already have some of them, in part or in all,  there in your development methods. Just revise the checklist and think of completing what you lack.  

In my personal experience along decades, even before these techniques were well developed, is  that thinking reusable (in the pre-oops style even), patternizing  solutions and requirement (even before GoF came up with their formal patterns) and thinking of testing as a driver to coding (somehow before formal TDD and its tooling), all that gave the development organization the vantage of Readiness to whatever solution they used to meet. We, implementing the three pillars in our old-fashioned ways,  very rarely had to “reinvent the wheel” in building a business application. Of course there will always be some deviations, problems that lie out of your context of Reusability , Patternization and Testology. But once you solved them, they will join your repository of Readiness, for future battles, anyways.

This is how to build your Readiness to reach almost perfect software, at a fraction of its cost.

Next installment, we discuss the impact of quality (quasi-perfection view) on the development team, not just the product, the customer and the market. The internal aspects of quality, if you like to call it.

See you, then.