Software challenges in the current climate -guest post

Today’s post is from my brother, some inspired thoughts about the new challenges within software design that was related to this article about the development that came with the new Chevy volt. The topic came about through exploring the type of challenges that come out of managing large, fragmented and modular projects such as was the case with the software and hardware development of the chevy volt.

Here was his thoughts about the tools that help to manage these types of development.

There are a few tools.  Most of the tools are practices more than actual software.  For example, to help minimize integration issues, larger projects will require things like

  • SRS’s (Software Requirements Specs)
  • Functional&Non-functional requirements
  • interface and API documentation

The catch is, though documentation helps alleviate the issue, it also generates yet another product that needs to be kept in sync with the code.  It is quite frequent to see documentation that is out of date with the code being developed, to the point where it is contradictory.

Other processes are things like change management, version control etc.  All intended to slow down changes (or properly version & control) changes made to program behaviour from an external perspective. Others help identify system risks (e.g., if I change this interface, what is the likely impact, what kind of bugs will it raise, how difficult or subtle will the change be etc.).

Some existing software tools simply work on trying to make this documentation “easier” to generate somehow.  These fall into two categories:

  • allowing code to be autogenned from the diagrams (aka “Any one can program it just requires design”… a mindset that has some truths, but can easily be taken to the point of ridiculous)
  • auto-genning diagrams from code (some fancy flow charts actually work quite well).

There are even some languages that specifically work to help this by using what’s called “design-by-contract” (http://en.wikipedia.org/wiki/Design_by_contract), the key one being Eiffel.  These still all suffer from the problem that your teams need to somehow work closely together.

I honestly think that tools like DVCS’s (e.g., Bazaar) help a lot with this, as it means changes can be passed around a distributed team or set of teams with much greater efficiency than traditional CVCS’s would ever allow.  But… as the article hints at, software management is still in its infancy, and really desperately needs better tooling and processes.

From my perspective & experience with the Linux world, high-level system integration really requires the following:

  • Small WELL-DEFINED parts.  Don’t make an all-singing-all-dancing part… it must always be small and very specific things.  This makes all the following easier to achieve
  • Frequent small updates to each component to allow behavioural changes to ripple out as quickly as possible.  This means jumping from version 1.0 to 2.0 shouldn’t happen all at once, but should roll out slowly as this allows both sides of the fence to more naturally integrate behaviours
  • Low level unit tests on both sides of the fence to ensure consistent behaviour internally
  • API level tests to ensure system behaviour remains fixed OR system behaviour changes are successfully identified (system being the overall code base, not just the internal bits that unit-tests target)
  • Integration tests all the way up (e.g.,  testing system A+B, then (A+B)+C)
  • Versioned API’s between components
  • Solid bug tracking & change tracking
  • All testing HIGHLY automated

A lot of this is actually pretty close to how linux works.  This doesn’t deal with people in various roles though, and factors such as committee vs. individual control (e.g., a person per component is probably a good way to go). Those require some more analysis into how much a human mind can hold, vs. how much benefit a collection of minds can hold vs. various trade-offs in knowledge etc. (e.g., democratic elections tend to mean a lot of people follow each other… so not everyone deserves a vote in software.  How many people should vote, and who should they be?)

Philip Peitsch.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *