Notes and drafts on hardware and software creation process analogies

Greg Bobrowski - Kanban in software


Process: Kaban - Lean - Agile - XP
How the process of designing Kanban plants differs from the process of designing assembly line plants.©

Introduction©

My astonishment with commercialization of creativity started years ago when I had heard about a company in London, England that offered to write a book, on any topic and in any style, and to put the order giver's name on it for a fee, of course.

Isn't software writing process more similar to movie making or book writing rather than it is to a mass production? The key difference is that industrial methods are geared towards minimization of a cost of making replicas. In software the main point is to add features. Software factory is a construction site ¹; one product only is being build.

The waterfall model, introduced early to software manufacturing was a foreign body in software community but its coming to existence reflected an urgent need to address the bean counting aspects of software production that emerged when the scale of the projects grew. Waterfall model implicitly assumed that no similar software had ever been written before; the state of technology required that SRS defines everything from architecture to the tiniest detail but it did not offer granularity in managing the process. One could say that waterfall was a management free software development model. Many iterative models started to compete with it very early. Their existence was crucial. These models let us pave unchartered waters with new concepts and the vocabularies. They provided technical and social grounds to challenge waterfall model.

Today most of software departments are run without making commitment to any well defined methodology or process. Making such a declaration is accepted only if it is needed for marketing purposes otherwise it is simply a burden. Most companies use some form of Agile methodology.

Extreme Programing, that is not really so extreme until one takes seriously the Pair Programming, hurt its acceptance and, simultaneously, got the most known of all of Agile spectrum due to the choice of its strong name. Who wants to go to extremes? High performance team, as in Formula 1, may require quite a solid backup and a team of coaches that cost you way more than your stage performers. Nevertheless, Pair Programming can be great, just think about Tom and Ray Magliozzi and their NPR Car Talk show. That is symbiotic, exquisite, the best in its kind pair programming ever. I love it. How do I setup a next pair like that? That's where the challenge starts. The Extreme Programming model states 'people first' and there is, I dare to suggest, not enough, prescriptive material offered on how to synthesize the perfect pairs.

As monumental, automated manufacturing collapses to give a way to cell based manufacturing and Waterfall matures and evolves to RUP² ; as CMMI 3 6 and Six Sigma provide metaprocess or process creation and improvement metodologies; the proponents of 'unified' software/hardware process get new energy in specifying their ideas. Drawing parallels between Kaban and Agile is very productive 4. Toyota's Kanban is a method to avoid over-production , software Kanban ought to be a technique to avoid over-engineering!!

How the manufacturing facilities are made©

One could say, that it is rather Kanban that was derived from software operating principles, such as the event driven control flow, rather than the software manufacturing methodology was derived from Kanban.

I see a considerable amount of similarities between how the software operates and how the manufacturing facility operates as opposed to the analogy between how software is made and how the facility operates. The second one is examined in a great detail by M. Poppendieck4, K. Hiranabe, D. Anderson 5 and a number of other prominent analysts. Therefore, let me examine only the key points that differ the process in which monumental manufacturing plants were developed and the process in which modern, light weight cell based plants are developed.

The pressure to shorten the product delivery cycle goes across all industries. Parallel design of components that depend on each other is a common practice of twenty first century despite the fact that designing them sequentially would be less labor wasteful. In explicit, the design of a manufacturing facility to make a part "A" starts only slightly later or simultaneously or even earlier than the design of a part "A" itself. The test hardware for Design Validation, Product Validation, Production QA, Product Configuration and Warranty Troubleshooting stations are designed in parallel.

The design of a subsystem starts as soon as the data to start the design is available. The design process, therefore, is a data driven one.

How the software is made©

What makes software different from any other product from a day one is that it was adapting to other human products, software and hardware, as opposed to traditional engineering fields, such as mechanics, architecture, construction that could ignore everything that was engineered before. For traditional engineers the waterfall model is the most intuitive one, a model that existed before models were named.

  • Software is created under a pressure to finish before standards change.
  • Software is created under a pressure to finish before a platform is outdated
  • Software is rewritten, just because the platform changed.
  • Software never wears out.
  • Software never brakes. It becomes broken by something.
  • Software is interactive.
  • Software depends on software around it.
    • Software depends on competitor product.
    • Software depends on multiple products.
  • Software architects do compete by submitting mock-ups.
  • Software melted with every part of our activity.
Software is not a sand castle. It is a castle on marshes. It drowns if it does not grow at a speed. Software is in a permanent state of explosion that draws in more and more people, penetrates further and further the space and accelerates every engineering and creativity that was ever conceived.

I believe that the main shift that happen in both the Manufacturing Unit design process and in the Software design process during last twenty years is that they switched from single threaded to multi threaded. To help imagination let's say twenty years ago we needed a system that keeps accountable one designer to produce a correct design in 356 days, today we need a system that assists 356 designers to produce a correct system in one day. Or looking at it from different angle, twenty years ago the management of a process was accountability oriented; today the management of a process is an integral and essential part of the process itself.

Another major shift that took place in a last quarter of a century is that software is not developed anymore by an elitary group of physicists, mathematicians and engineers. Software development had moved from a pure art, a pure skill to a knowledge based activity. Software programmers became more similar to doctors and lawyers than they are to free spirits they used to be. The software profession diversified and stratified. SOA came as the newest incarnation of returning melody about re-usability, separation of concerns and, above all, about the basic observation that software needs to be build a purpose and not the other way around.

Finally, I suggest that the fact that most machines run on a single CPU comes not from the technology limitations but from limitations of human line of thinking. In fact, we were pushed into multi-threading by speed limitations of IO and into multiprocessor in a struggle to inch a bit more processing power. That is, our mindset is fundamentally single threaded, while the physical world is not. Not long ago, if one was offered multiprocessor system the overwhelming thought that stroked him was "what would I do with it?". Indeed, except for weather modeling and fast graphic not much use was conceived for multiprocessor machine up until quite recently. It is not our mind that is single threaded, it is a bit our vocal predispositions and a burden of our civilization build around single threaded ways of expressing our thoughts by speech and in writing. It is a conventional ways of communication that slow us down to a single thread. These ways are precision oriented, almost hostile to the addressee, meant to write down laws and commands. It is recognized, however, that we communicate in more than one thread, body language carries more than 50% of the content and, occasionally, overrides the verbalized message.

Proposed here the Cycle Minimization Oriented Process, in short, CMOP ©, concentrates on reducing SDLC via unconventional ways that the communication is handled.

CMOP©, recognizes a dynamic character of technical and business environment in which software emerges and continues to dwell. CMOP©, recognizes importance of the software requirements management, software specification propagation and knowledge based rather than ability based character of effort undertaken by individuals working on software development.

i

CMOP© in a nut shell

on request only, fill 'Feedback:' below



1 M. Fowler
2 RUP
3a, 3b, 3c 3dCMMI
4 M. Poppendieck
5 D. Anderson
6 K. Trethewey: The difference between Agile methods and CMMI
7www.sei.cmu.edu/cmmi: Dalton Agile-CMMI
8 www.agilemanagement.net: D. Anrerson: Stretching Agile to Fit CMMI Level 3
9 www.cmcrossroads.com: Continuous Integration




Feedback:


Kanban, Free download, free software, freeware, trial version, methodology, CMMI, Six sigma, Free download, free software, freeware, trial version
TKO's Application Life Cycle 2.0 recognized that fast growth of complexity of software will drive up quickly the cost of maintaining diversified hardware and software environments, therefore it promotes virtualization as a means to reduce the cost of maintaining environments, essentially, by timesharing of resources.