Platforms, SDLCs and "industrial engineering for software development"

In this post, I will try to synthesize into a single theme a few ideas that have been bubbling under in our DCG Research discussion in the past months.  I am sure that I will fail but I want to share the current state of our thoughts with this community and, hopefully, get some feedback. Thought #1:  The software industry seems to go through cycles of diversification and consolidation. Examples are well known: Consolidation for years around the IBM PC and windows preceded by diverse environment that included many personal computer architectures and followed by a world with Apple macs, PlayStation's and Linux.  Right now, we believe that we are in a diversification cycle.  This poses the standard "diversification cycle challenges for software engineering departments around choosing which diversified options to support and how far to go in moving from the simple ideal (a single code base - constantly changing as the external options change) to chaos (a different code base for every option and/or customer). Thought #2: Despite the globalization of functional needs for software that has driven some commonality of approach e.g. website/portals, SaaS, broad scope enterprise software megaliths, there is still an expectation of significant local control and customization of the user interface. Thought #3:  In most organizations, there is no obvious individual, group or team responsible for managing or enabling the simplification and efficiency of the end-to-end process of getting the best version of the code changed to meet the latest needs an then managing that version for its lifetime.  Too often, so called "process improvement" groups (if they exist) are focused on change management and the associated, necessary metrics and bureaucracy.  They focus on improving the macro processes not the micro processes. Thought #4: When I was an undergraduate, I joined a company called Plessey as a "sandwich student" ("Co-op" for my American readers).  Plessey was a multi-faceted electronics company but I worked in the avionics and communications factory in Ilford, Essex (it's now a housing development).  The training program included spending 2-3 months in most of the various departments that made the factory work including my favorite, "Industrial Engineering."  This department's goal was to make the production process as smooth and efficient as possible.  It's responsibilities included continuous improvement of the production efficiency and I spent time designing tools or tool jigs (yes, I'm that old), programming NC and CNC machines, redesigning shop floor layouts, writing processes for building circuit boards and so on.  Some of the production processes we worked on had a line manufacturing model ( I think I will call that "waterfall" and some had a jobbing model where a small team worked together to produce a finished article ("agile" anyone?).  In some ways, you could label the work we did, "process improvement," but looking back and comparing t to the work that today's process improvement teams in software organizations are responsible for, industrial engineering was (is?) so much more.  The major extra value provided by the industrial engineering team at Plessey was in building or buying tools to make the production process more efficient.  That team was also the first to be called when there was a problem in production.  For example, if some new component met all the specifications but had some unspecified characteristic that "broke" the current process, industrial engineering would be brought in to do a root cause analysis but also to find an immediate fix. Synthesizing these thoughts leads us to the idea of a new discipline in software development organizations that is responsible for production and for making production more efficient.  Industrial Engineering for Software Development. This group could/should help with the challenges of dealing with multiple target platforms the complexity associated with:

    • multiple target plaftorms
    • multiple concurrent production approaches
    • short term production problems
    • long term root cause analysis
    • Bridging the different needs of the following teams:
  • Architects
  • Coders
  • Unit testers
  • Configuration Management
  • Release management
  • Integration testers
  • Performance testers
  • Deployment environment managers
  • Open source and license managers
  • Process improvement teams (this could be a part of the new industrial engineering group)

We have not seem this type of function organized explicitly in software development groups.  All the jobs somehow get done and the quality of the software development is directly proportional to the clarity with which these task get handled.  Unfortunately, many software development groups survive by controlling their environment in such a way as to exclude the diversity that makes these challenges worse. I will conclude this post  with the concern that in this current diversification phase, trying to "lock out" diversification may not be an option.

Written by Michael D. Harris at 12:10
Categories :



"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!