When a "bus problem" becomes a reality it's critical to address the human needs first. This post does not provide guidance on how to deal with loss, but if you're in a leadership position you need to know how to appropriately respond or where to go for help.
Ultimately if you hold a key position in your organization (e.g. reputable architect or a trusted advisor) you may be called upon to help right away. Your first order of business should be to get the software solution up and running by all means necessary. Be prepared to look at the source code, log files, incomplete documentation, conduct interviews with frustrated users. You will be looked upon as a savior whether you're ready or not, so you must be prepared to act like a Swiss army knife. In this situation the pressure is high and failure is not an option.
Here are the guidelines to help you think when under pressure:
- Create a plan of action. Write down everything you think you need to do. Use this list as a start.
- Understand the business need and function of the solution. Bus problems usually don't occur on properly managed large scale solutions with a clear mission. There is a very good chance the solution affected by a bus problem supports informal business processes that you don't know about.
- Learn everything you can about the solution. Seek people who may have worked on the previous version, seek hard copies of presentations and documentation if soft copies are not available.
- Think about the technical aspects of the solution. Based on the technologies used and your experience with the application (if any) you may make some assumptions about architectural patterns used. But be careful assuming that the patterns are being used correctly. An opportunistic solution is very likely to have improperly used (or misused) architectural patterns or simply poor implementation. Hope for the best, but expect spaghetti code.
- If you're not proficient with the technology used find a smart software engineer to work with you side-by-side. At this stage this person will be your partner - not a subordinate.
- Be aware of the political landscape. If the solution in question was developed and managed by a different organization devise a strategy with your senior leadership to diplomatically address this issue. The organization owning a failed solution may be well aware that they were irresponsible by letting the affected solution operate in such manner. Think about an exit strategy for the responsible organization to gracefully "save face."
- Write a short draft proposal (1 or 2 pages) of how the broken solution should evolve into a mature environment so that it can be supported by your organization's IT. You will have ideas as soon as you start looking at this problem so you may as well write them down from the perspective of your organization's computing infrastructure.
This is not a complete list, but it will help you handle the knee jerk reaction you may be expected to perform. Act quickly, but systematically. Understand the business value of the solution that's hidden from the official view, get the solution up and running immediately by using whatever it takes approach, rapidly evaluate near term needs, and think about the long term needs.
You may want to bookmark this post so that you can find it quickly in the time of need.
I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...
Great blog post by Agile Journeyman about Martin Fowler's Design Stamina Hypothesis & the Technical Debt Quadrant. Constantin K...
Agile processes give you an ability to do something faster. Often agile approaches give you an ability to deliver smaller chunks of software...
From the SEI podcast series: "We know from existing SEI work on attribute-driven design, Quality Attribute Workshops, and the Ar...