Software development, can we learn from Manufacturing?
I remember when I joined HP and started to work with the manufacturing industry, there was a concept that became quite popular quickly. It was called “Design for Manufacturability” (known as DFM). The concept was simple, involve the people that have to manufacture the product you design in the process and they will tell you the manufacturing implications (cost, yield, time) of the design decisions you take. What a concept, isn’t it?
Before this, the design engineers had been developing wonderful products and then thrown them over the wall to the manufacturing guys telling them, just go and make the product.
A second concept that became popular was called “concurrent engineering”. It started from the concept that the actual design of the product, the design of the manufacturing tools & facilities, packaging design, procurements of supplier parts, development of diagnostics and other tools etc. would be designed in parallel (hence the term concurrent). The advantage is that the ripple effect of decisions are analyzed and decided upon quickly. It speeds up the overall design process and reduces the time it takes to get the design in production while reducing manufacturing & warranty costs.
An article from Alemu Moges Belay analyzes both methods and finds out that by using those methods and by forming multi-disciplinary team in designing and quality inspection, the companies can reduce the workflow steps from 40 to 30, drastically reducing time to market.
The DevOps revolution
How often have we seen software developers throwing the code over the wall once it’s ready for production for the operations team to pick up and make available to the users without even thinking about how the software actually has to be installed and maintained.
Development and Operations are two different worlds, as are product developers and manufacturing engineers. They don’t regard each-other highly; feel the issues are always due to the other party. But lately I have seen people realizing that, working more closely together can reduce time to market and provide end-user with the required functionality faster.
Is DevOps the DFM of software? Can we get increased collaboration between development, testing, infrastructure and operations teams, breaking down IT silos so they can deliver high-quality, innovative applications for hybrid and cloud environment s faster? That’s the intention. But that requires continuous communication and collaboration. And that is where tools help.
For this reason, HP updated its well-known Application Lifecycle Management (ALM) platform including pre-configured reports with on-going information about the progress of application development. By integrating ALM with HP’s Enterprise Collaboration software, a social media style of communication is available. Context-based conversations between key stakeholders across the application life cycle can now take place. Users can now:
- Make faster and more accurate decisions through better collaboration among application delivery teams. Teams can now work together on requirements, create RSS feed alerts and support progress discussions on development status, test runs and defects.
- Improve developer efficiency with the enhanced HP Application Lifecycle Intelligence 2.6, a key component of HP ALM that adds support for Git—an open-source version control system—and source-code management software, in addition to existing development tools and integrations.
These tools form a good basis for agile development. But I believe we can do more. My good friend Paul Muller (@xthestreams) sent me a couple days ago the link to two sites talking about the management aspects of agile, kanban and lean. Hang on, that’s something I know pretty well. I remember how we trained our teams on just in time (the way kanban was called in Europe and the US in those days), I’ve been discussing lean manufacturing with many customers over the years, and agile development methodologies are a nice addition.
So, could we complement the tools I talked about earlier with a Kanban approach where you only develop what is needed when it’s needed removes a lot of waste in the system. How do you get there, well follow the lean/six sigma principles. Analyse the existing approach and separate the productive and non-productive tasks. The latter are overburden (mudi), inconsistency (mura) and waste (muda) as defined by the Toyota Production System.
Ruthlessly eliminate those as they add no business value. Learn from what was done in manufacturing, and even if the terminology may be different, take the time to understand the essence and inplement it. For an intro to the concepts of lean, you may go here.
Researching for this blog, I ran into a quote from Edward Deming that’s pretty relevant: “What we need to do is learn to work in the system, by which I mean that everybody, every team, every platform, every division, every component is there not for individual competitive profit or recognition, but for contribution to the system as a whole on a win-win basis."
How do we improve in development?
Last January I was in the bay area, speaking with some of our development teams. In particular, I reviewed a large project in which I have a special interest (will talk to you about that later). I became really curious when my contact told me the developments took place in 7 locations concurrently, including China, Europe, Israel and a couple locations in the US. He told me that at the end of their day, each team checks what they have done back into a common system and that overnight California time, all modules are assembled automatically and a series of tests are run. The feedback is distributed to the teams mid-day California time. Wow, I was impressed.
My contact added that this allowed them to speed-up the development process drastically as it gave them the opportunity to do integration testing daily rather than weekly, and it reduced the typical time to run the tests from 1 day to 3-4 hours. This got stuck in the back of my mind.
But can we really use those technologies in software development? Would they help getting better quality software faster to market? That’s the fundamental question.
Well, let me give you the scope. HP is announcing two new functionalities to support such improvements:
- HP Lab Management Automation for HP ALM and Performance Center accelerates the deployment of high quality applications by automating the configuration of testing environments to align with real-world scenarios such as private and hybrid clouds.
- Continuous Application Performance Delivery enables operations and testing teams to share real-time performance data for use in application performance testing scripts.
With these, clients can now:
- Identify and diagnose potential performance bottlenecks by importing production monitoring data from HP Business Service Management software and third-party tools.
- Further accelerate test configuration by importing application monitoring metrics from HP SiteScope
Conclusion
By improving collaboration between the development and operations teams we can drastically speed-up the time to market for applications while improving quality and performance. This is critical for cloud environments. Paul Muller points out that, as walls come tumbling down, devops improves agility and continuous delivery. HP has developed the tools to support such new integrated development. Why do you not take advantage of that? Also, look at the experience gained in the manufacturing space, it’s very relevant to what you may want to do in the development and operation space.
