Keeping the light on
Top priority being a thing usually means that delivering the current solution is taking for granted. People not concerned with customer value or product development can have lots of opinions on what should be developed next or what should be the top priority. A simple test to check if something is really "top priority" a good question to ask is: If our current system breaks down and becomes unusable to our customers would we leave it dead and continue working on the top priority? If the answer is no, then you aren't really talking about a top priority, only high priority.
A key attribute of dev-ops is the single team that does both product development as well as run the system. There are several good things about dev-ops but the corner stone of being responsible for both development and run makes a lot of sense. Sure it's sometimes a pain, but only good product design and solid engineering can remove that pain, that is why the feedback loop of doing both development and operations is so important.
After a while of getting "feedback" as in having to fix issues learnings from this work will eventually lead to a more robust and resilient system as well as a stronger competence on how to build things that don't break in the first place. Frequently teams that are struggling with supporting their service have not been allowed to invest enough to avoid incidents from reoccurring and will due to this waste time putting out fires, getting out of this bad position is difficult since it requires doing to important things at almost the same time.
Every once in a while greater leaps need to be taken and those are usually both exciting and scary from an engineering point of view but by not rushing and thinking carefully on deployment and release most unknowns can be ironed out or at least side effects kept to a minimum. For changes like these it can be a good idea to keep a budget, only allow one big technical leap or major architecture change at the time. This also means trying not to scrap everything at once because having something to compare with and something to fall back on while fixing things allows a more clear headed thought process.
Although I don't recommend sacrificing stability in production for short term feature development (it will bite you in the long-term) there are situations where it can make sense, if your current product is lacking customer impact or simply not reaching the customers it makes sense to be more aggressive.
A key attribute of dev-ops is the single team that does both product development as well as run the system. There are several good things about dev-ops but the corner stone of being responsible for both development and run makes a lot of sense. Sure it's sometimes a pain, but only good product design and solid engineering can remove that pain, that is why the feedback loop of doing both development and operations is so important.
After a while of getting "feedback" as in having to fix issues learnings from this work will eventually lead to a more robust and resilient system as well as a stronger competence on how to build things that don't break in the first place. Frequently teams that are struggling with supporting their service have not been allowed to invest enough to avoid incidents from reoccurring and will due to this waste time putting out fires, getting out of this bad position is difficult since it requires doing to important things at almost the same time.
Every once in a while greater leaps need to be taken and those are usually both exciting and scary from an engineering point of view but by not rushing and thinking carefully on deployment and release most unknowns can be ironed out or at least side effects kept to a minimum. For changes like these it can be a good idea to keep a budget, only allow one big technical leap or major architecture change at the time. This also means trying not to scrap everything at once because having something to compare with and something to fall back on while fixing things allows a more clear headed thought process.
Although I don't recommend sacrificing stability in production for short term feature development (it will bite you in the long-term) there are situations where it can make sense, if your current product is lacking customer impact or simply not reaching the customers it makes sense to be more aggressive.
Comments
Post a Comment