When designing software on a project-by-project basis, there is a need to anticipate and look at the bigger picture. Even after that awesome phase when the project is, to all intents and purposes, in the bag. In this blog, I will provide a few thought-provoking ideas for the post-honeymoon period in software development.
I have recently been taking some time to re-think the topic of continuity management in software projects and how best to respond to concerns and questions in this area. In the current climate, the issue of personal risk is understandably at the forefront of our minds. This has led to a situation in which two distinct phenomena seem to emerge time and again. Phenomenon One: there’s a small DevOps team independently responsible for developing and maintaining a package, which may, in fact, turn out to be quite large. Phenomenon Two: the "Well, didn’t some Joe or other code this?!" school of thought. Before long, the latter approach of relying on someone or other’s hastily doodled code accidently becomes business critical. Fortunately, there are good solutions to both of these areas of concern, and now is precisely the right time to think long and hard about them.
The smaller the team, the more real the risks
In the DevOps philosophy, development teams are responsible for operationalizing and maintaining their own output. And while the idea behind this is sound and often works well in practice, this arrangement brings its own challenges. Industry blogs regale us with success stories from around the world and we eagerly read all about the positive experiences and effective practices of Google, Netflix, Spotify and friends. After all, isn’t that exactly what we should be doing, too? But then the reality of the difference in scale kicks in.
For example, it’s much easier to manage personal risk by rotating hundreds or thousands of developers between teams. But if we’re talking about a single team of four individuals, the dynamics are inevitably very different.
Another challenge posed by DevOps relates to the lifecycle phase of the software under development. After all, it makes sense that rather than a small part of the package being continually developed at high capacity in project mode, it is instead transitioned onto a maintenance and low-end development lifecycle. In fact, it’s often not worthwhile committing a single full-time person to develop and maintain the software. Therein lies the personal risk.
The digital lifecycle is not just load of buzz words
At Vincit, we set out to respond to these challenges, and our approach has become the core of our DiPS (Digital Platform Services). We strive to safeguard our customers software investments throughout their lifecycle, and we pay particular attention to eliminating personal risks and providing our customers with the opportunity to further develop their software with the degree of intensity they choose.
So, what about Joe’s code doodles? Fear not. This issue can be tackled with much the same set of tools. In the meantime, though, we have to do some so-called software archeology. But seeing as even the coolest member of our team relishes this kind of job, for us it’s no biggie. In practice, then, the software in question should be reverse modeled to a level sufficient to guarantee its continuity and possible further development as needed.
If you are looking for a return on your software investment and want to minimize the risks along the way, I think it might be time for us to have a chat. In fact, why not call me up now rather than when the matter becomes more urgent?
Did you enjoy this article?
Give us a clap!