Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Software Development as a Design Process

DZone 's Guide to

Software Development as a Design Process

Changing the way that we think about software development can better reveal the purpose of concepts like DevOps and continous delivery.

· Agile Zone ·
Free Resource

The book Agile IT Organization Design - for Digital Transformation and Continuous Delivery by Sriram Narayan explains software development as a design process. The following statement from the book means a lot.

"Software development is a design process, and the production environment is the factory where product takes place. IT Ops work to keep the factory running.."

It questions the way we traditionally think of operation support, maintenance, production bugs, rework, their costs and budgets and the focus in software development life.

Thinking of software development as a design process helps the organization focus on today's need for Agile development. Here are some thought points, when anything before production deployment is considered as software product design, and the "software product" is getting produced from the production environment (factory):

  • Dev + Ops A product design which doesn't fit in the process of a factory cannot be produced by the factory. In other words, a factory which has sufficient resources needed to produce a given design can't produce the product. The product designer and factory operators need to be in a closely collaborated team, to improvise the design, and do production.
  • Continuous Delivery There is no point of thinking about the factory after the product design is done, as we may not be able to build the factory optimally. Think of the production factory while designing the product. Have continuous feedback in place by continuous integration and delivery.
  • Value-driven and outcome-oriented teams — A factory can produce the product on a shop floor/production line with checks, balances, and integration at each step. It applies to software development as well, value-driven projects, and outcome-oriented teams are more helpful in making product successful over the plan driven projects and activity orientated teams. The book covers it very well.
  • Sorter cycle time — Software product design has no value until it is produced and provided to the people. The sooner we produce, the better value we get — so the cycle time for product design must be as small as possible. Luckily, in software development, we have tools to simulate factory environment/test labs, and try to produce the models well before the actual production.
  • Measure the product quality more than the design quality — It is important to measure product quality more than that of the product design (software before the production environment). So metrics which can really measure product quality (software running in production environment) such as velocity in term of "value." Measuring burn-up/burn-down, bugs counts, defect density, code review quality are all product design metrics, it may not matter how good these numbers are if the software is not producing value on the production environment.

Conclusion

The book covers an Agile organization design with a great breadth and depth on structural, cultural, operational, political and physical aspects. We can relate many of these aspects while thinking the software development as a design process.

Topics:
enterprise agile ,agile design ,software process ,design process ,devops ,continous delivery ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}