Software engineering universals: where to start?

Our previous post “What is the Scope of the Kernel” presented a list of candidate features for the kernel. The ensuing discussions focused in particular on how judgmental we should be in analyzing current methods and practices, and what would be a good starting point for building the kernel.

All participants appear to agree on the existence of a kernel: a core of concepts (“universals”) essential to all software engineering efforts. This unanimity unfortunately vanishes when we get down to specifics: defining what the universals are and what makes them essential. The purpose of this post is to advance the search for software engineering essentials.

We must keep in mind Jim Maher’s injunction to focus on the “what” and not the “how”. When we look for universal elements of methods and practices, much of what naturally comes to mind belongs to the “how” category:

  • Work Products such as models, plans, specifications and even the source code are different kinds of descriptions of the software.

  • Activities such as planning, writing a requirement, devising a model are descriptions of work to do.

  • Roles such as programmer, or database administrator are specifications of specific jobs, the skills they require and their positioning in the team

Such descriptions are all important, but at this stage of the Semat discussions it is premature to devote our efforts to the means while we have not yet defined the ends precisely.

Some of the previous postings made suggestions that help address the what before the how. Skip Pelcher wrote:

“Work products (including the delivered software) exist to fill some need; other products might satisfy that need. And the order of the production of the work products is not pre-determined.

Perhaps an artefact-centric approach would better serve as a method for testing whether the framework is complete enough to support production of standard work products.”

Mark Kennaley pointed out that

“If we were to take a Lean Thinking approach to this, we would end up with ’working, tested software’ as the only work product that should be the output.”

Taking for granted that “working software” is among the essentials and is a “what”, can we take it as the starting point?  How is it related to the Semat triptych of work product, activity, and role?

The concept of working software is associated with many work products, including:

  • Source code.

  • Object code.

  • Installation guide.

  • Design model.

  • Release description.

  • Help file.

  • Test script.

  • Test result.

  • Test harness.

  • Defect report.

The actual set of work products and their specific formats are dependent on the practices and methods used.

Producing working software is also associated with many activities (such as write tests, write code, run tests, write help, build software) and roles involved (such as programmer, tester, architect, build engineer). Again these are all method or practice dependent.

So here is our proposal. Let us not reach for the stars yet. Let us take the one universal that commands universal agreement, Working Software, and discuss it inside out until we are ready to include it, through a detailed and convincing description, in the Semat kernel.

— Ivar Jacobson, Bertrand Meyer, Richard Soley

No comments yet. Be the first.