Quality and Innovation

A couple weeks ago I presented my perspective on Why Software Reuse is Hard. I also posted a link on LinkedIn, and wanted to capture the comments that were received there. I think it’s interesting to note how many people support the concept of continuous learning for competitive advantage in software development – without actually saying it!

Mike Duskis – Software Quality Lead at CaridianBCT says:

I like the distinction between “black box” code that we can simply plug in on one hand and code that we need to understand “tacitly” on the other. I think that, deep down, most of us software geeks would love to experiment with the innards of every interesting gadget that we can get our hands on. That’s what makes us geeks.

In the real world, we can’t let our geek nature control us. We also need to be pragmatic engineers, producing optimal solutions with minimal waste. This is what drives us to adopt code written by someone else.

But the issue cannot be boiled down to a primal conflict between the inner geek and the outer engineer. As Nicole’s headline implies, software reuse is hard. Even after we make the decision to reuse existing code, we face all sorts of obstacles. There is a whole lot of lousy code floating around out there. In fact, I would argue that most code available for reuse is poorly designed, badly documented, and ripe for mishap or exploit. Doubters might tour a few random projects at sourceforge.net . The good ones are very good, but they are vastly outnumbered. The only way to know for sure that a component is not lousy is to tear it open and examine its guts, but doing so would expend the very resources that we are trying to save. Even if we assume that the code is not lousy outright, its developer was probably motivated by different problems and circumstances than we face. Ironically, the more efficient the original developer was, the less likely it is that he produced something that can simply be plugged in to a completely different environment.

Over the years, languages, patterns, and paradigms have evolved to help us to resolve these difficulties, but there is always a cost. Java almost forces us to produce reusable components but at the cost of a cumbersome paradigm that encourages over-engineering. At the other end of the spectrum, Perl and Python are easy to use. They also encourage the development of quick-and-dirty code that can be very hard to reuse. I suspect I’ll get some flack for this, but I’ve struggled with both extremes enough to develop “tacit” knowledge of them. If there is a happy medium, I think it lies in a way of thinking rather than a language, but every step that we take from the extreme represented by orthodox JEE (with beans) is a step away from the “black box” that allows us to simply plug a component in and forget about it.

On balance, I think that reuse is not only desirable but necessary. Who has time to design new systems from the operating system on up to the code that actually solves our business problem? The trick is figuring out how to do it well.

Greg Zimmerman, Owner, Applied Quality Solutions LLC & Regional Councilor, ASQ Software Division says:

There’s no magic way to make reuse easier, but you can attempt to create a normalizing factor with service frameworks that define the structures, relationships, and communications. On top of that, build code generation tools that automactically create the common components within and around the objects.

I say this as though it’s simple. Nothing can be farther from the truth. It’s taken us the better part of three years to reach the point where this has become standard practice for new services. Integrating / updating existing services is still a challenge.

I guess I’ve just reiterated the point that reuse is hard, but as Nicole said, it’s not impossible. It requires committment from both developers and managers, and the patience (and funding) to lay the groundwork.

Steven Rakitin – Software Consulting, Training, Facilitating, and Auditing says:

Nicole there are several other reasons why software reuse is hard that have nothing to do with the forms of knowledge that you talked about. Imagine trying to come up with a reusable design for a new product. In order for the design to be truly reuseable, the designer would need to know the possible ways the design will be used in the future. If that information or knowledge does not exist, it becomes very difficult to design something that is truly reusable…

Reuse was a vary popular issue back in the 1980s and people envisioned “software factories” cranking out reusable, modular components that could be designed and tested once and reused many times. About the closest we’ve ever come to achieving that goal is defining standard interfaces (APIs) that designers can design to…

It’s hard because everytime we design a new app, we want to start from scratch… just the nature of software engineering and software engineers…

-Steve Rakitin-

Bryce Bolton – Electrical Engineer, Prof. Research Assistant at LASP / University of Colorado

Personalities and architecture are part of the difficulty.

Personalities: Everyone wants to do things their own way, and if they can’t quickly understand the architecture, or don’t like it, they will re-create it into something they understand.

Architecture: Even the best architectures create ongoing debates. Consider the battles between languages like Perl and Python. Verilog and VHDL, C and ADA. In each case, the first language is more freestyle & flexible while the second is more structured. This creates endless preference debates on a language level. Within teams there could be even more differences.

Good system architects within the projects lead the team toward a standard which is adopted by the other team members. So lack of reuse, or spaghetti code could indicate a lack of leadership in the team.

To converge, some team members must force their structure on others, or management must resolve to come up with a standard to overcome the “style battles”. Getting team members working together on this, and putting team members with different styles together on a project may help smooth differences.

Or, the organization could suggest a 3rd party platform or OS from which the project-specific standard is derived.

The goal isn’t to make everything reused or rigid, except where project requirements mandate that. The goal is to meet the system requirements, including reliability. So, if reuse means designing to a coding style that increases quality, then the effort matches programmatic requirements. If the code will not be reused, it is wasteful of project resources to design to something outside the scope of the project, even if it is an ideal.

We typically working within a project, not fully on ancillary goals or ideals. Yet, if functional teams do not gel and create standards across projects, all projects will be less effective.

Reuse is of particular interest in product platforms and successive projects where teams are re-using each others code anyhow. At some point it will pay off to converge on a coding style. Seeing this and pushing for such commonality is up to management or enlightened team members. In the beginning, though, it may be less likely to invest in reuse. The situation may be one of more rhetoric and less consensus.

Bryce Bolton

Alex Elentukh – Quality Assurance Director, Program Manager, Process Architect, Consultant, Writer

At my last engagement we had some significant progress with reusable test components. These are fully supported by BPT feature of Quality Center of HP. Component-based test design allows to curb the number of tests. Otherwise tests were growing into an unmanageable mass of many thousands. A predictable lesson from this experience is that reuse must be supported by tools and deployed with great care and attention. For example, there should be provision to regularly review, communicate and measure reusable components

Emmett Dignan – Experienced systems and software professional

How many of the issues of reuseability are simply issues of poor documentation, overly complex or overly large code blocks?

I have seen an organization use an internally developed library of functional modules for regularly reused needs. But it required a dragon of a software manager devoted to the concept.

But development time dropped substantially if you could just drop a known and tested module into the framework for the next program.

Would UML help with this?