Working with the Medium
Software engineering is a relatively new engineering discipline. I tend to think that software development is closer to a practice than an engineering discipline. Just like medicine and law, the industry is ever changing and evolving, and sometimes we don’t know what we are doing. The process around software development can come in many forms, Waterfall, CMMI, Scrum, Lean, etc.
Each development process can be successful for many difference types of software. But there are cases when I think we, as software professionals, forget the medium we are working within. Like artists and craftsmen knowing and respecting the medium you are working within is key. A sculptor uses different tools and practices when they work in clay then when they work in marble. There is a big difference between software that is build to power a satellite than the software that powers an commerce site. Careful here I am not suggesting that one type of software development is more difficult or has great importance than another. My point is that each deployment target warrants a different process.
This may seem obvious, but I have seen many instances when this is not taken into account. Mistakes can be made on both ends of the spectrum. Investing little to nothing in testing and environment simulation for software that can only be updated on a major release cadence. Or, holding on to software, building out huge investments in automated testing for a web site that can be updated multiple times per day.
I have seen this happen most when a team moves from building software for one medium into another. A team that has built skills and focus on building out large testing infrastructures for an application delivered every few years may not be prepared to change this when building a web application. In my experience this happens because people like to continue successful practices. Makes sense, if you found that building out a multi-level review processes has kept bad changes from making it into a product, then why would you want to stop that process? For one reason, the variables have changed.
Each medium that we target has a different set of variables. Requirement gathering, design, testing, environment simulation, deployment strategy, shipping cadence, are all variables that change when the target changes. Really thinking about the application environment can be a beneficial exercise. How will you deploy your application? On what cadence will you update? You may need to abandon practices that are not necessary in the new medium, and adopt new practices where you don’t have skills.
You may also need to evaluate the development process you are following. When you are shipping on a multi-year cadence utilizing scrum with a 2-4 week sprint schedule is incredibly productive. But if you are shipping updates multiple times per day, then even a 2 week sprint does not really make sense. A process that utilizes Kanban to track the flow of value is more productive.
The dynamic nature software development is one of the reason I love this industry. We can get stuck in our ways, continuing to apply the same practices even when the medium we are working within has changed. Embrace the change, it gives us an opportunity to learn and grow. Think about how you have been developing software, what would you change? Are you resisting the medium or are you working with the medium?