This is part 2 of last week’s episode. In this episode we’re looking at foundational stuff: In order to be successful you must first define success and then orient your actions in a way that moves you towards success. When applying this mindset to software, we have a range of outcomes over which we measure success. As we drill into each one we find there are areas where we can take action to improve our outcomes.
In this episode we’re closing off the remaining 4 outcomes for success in software development. In the first episode we covered Rapid Delivery, Available & Scalable and Secure.
Remember, you can always read the 7 outcomes on the 345 site here. The last 4 outcomes discussed in this episode are:
Quality & Bug-Free
- Quality in software is layered, we approach it in a number of ways:
- Does the solution meet design intent? (This can be tech design and product design)
- Does the code pass static analysis, does it appear to be well written?
- Does the code pass unit tests, and is code coverage sufficient?
- Does the solution work when integrated with the other components?
- Does the solution meet non-functional goals such as performance and resilience?
- Does the usability meet the needs of the users? Do users love the solution?
- Each of these layers of quality control needs a different approach to testing and quality assurance. Each of these layers needs to be built into the process. Automate as many as you can.
- The hardest quality tests to automate are the ones around capturing design intent and assessing usability.
- Organisations that feel they are spending too much on building and operating their technology first need to get a handle on where they are spending their money.
- A high spend on CapEx used to come with investment in large quantities of hardware, datacentres and even licences. If this is the main problem and it’s draining cash from your business make sure you really need hardware! Most businesses now should be able to operate with virtually no on-premise servers. It’s only when you’re still running legacy mainframes and minicomputers that you should be struggling here. Cloud can help, and if you’re really pushed look at building a private cloud with some decent virtualisation technology.
- A high spend on OpEx can often come as a result of underperformance in some of the other areas. Operational spend on customer support, data entry and other manual processing can be a result of functional gaps in the software. High tech support costs can be a result of poor quality, with callouts to investigate and fix errors.
- High OpEx can also be a symptom of poor technology choice, or inappropriate solution.
- When there are high development costs we need to break down where the spend is:
- High spend on testing is often a result of lack of automation. To fox, reduce the toil and get your testing processes automated.
- High spend on developers can be a symptom of inappropriate technology choice (wrong tools for the job), inappropriate solution design (excessive complexity / excessive cross-dependencies) or wrong skills.
- High spend on architecture, analysis and design can be a symptom when organisations lack a delivery culture and produce documents as a displacement activity to avoid delivering anything tangible.
Functional & Lovable
- We define software as being functional when it meets all required functions, and we’re not using manual work-arounds to fill gaps in our business processes where the software should be. We’re taking opportunities in our business and delivering success.
- When we struggle to meet our functional goals, it can be for a number of reasons. It can be a symptom of the fact that we’ve delivered too slowly and run out of budget, and hence cut scope. It can be because we’re struggling to implement a poor design or use the wrong technology.
- Lovable software is another level. This is where our users connect emotionally with our software. It’s the vibe you get from Apple. It’s competitive advantage, it’s a reason why you get chosen ahead of your competitors.
- Our 6-Strata framework has specific areas where we look at emotional design. When we lack emotional design the first place we look is at the mix of personalities and skills in the team. It’s generally a different mindset / worldview, not just a different skillset, that produces lovable design.
- Standards are becoming an increasing part of our lives, whether we like it or not.
- Most busineses will find themselves affected by GDPR, accessibility, PCI-DSS or other general standards. Regulated businesses will need to meet standards specific to their industry.
- This outcome is not to be read as “am I standards compliant or not” – we find business that need to be generally are. The question is more like “am I able to meet the required standards easily, without negatively impacting my business”.
- If you’re finding it hard to meet standards it’s often a symptom that you have chosen the wrong technology or you have problems in solution architecture.
You can watch the video here:
You can listen to the audio version here: