The Wrong Patterns

Almost every organisation I visit in this DevOps world is obsessed by ‘technical debt’ – and consumed with guilt, hatred and loathing; well – perhaps that’s a bit harsh but……..

I find the obsession frustrating because it is all too often nebulous and therefore can’t be fixed or leads to an incorrect hypothesis about where problems lie.

These are some of the warning signs that I see people focus; often incorrectly & which lead to frustration and an inability to move forward.

I am keen to help anyone avoid these technical debt mistakes…..

1. Code Quality
Trying to ‘fix’ code quality across an entire legacy code base is not sensible.

* Languages, skills and coding techniques have changed – live with it.
* Define standards, write style and convention guides and test code going forward & maintain this approach – apply them sensitively to legacy code bases
* Don’t point a static code analysis tool at your entire code base and expect anything but pain
* Don’t try to refactor all your code to modern standards
* Fixing legacy issues should be based on metrics such as defect rate, bugs and adding new functionality

2. Run-book
Paper run-books should be burned and organisations with no run book deserve to suffer pain.

Failing to use a build pipeline|toolchain or run-book automation is a cardinal sin, don’t settle for people running complex IT release processes interactively.
* tools have existed to automate processes have existed for more than a decade; many are very good
* root|Administrator logging on to a system after development should be a reason for dismissal – perhaps a bit harsh but only perhaps
* trust the efficacy of anything done by humans with the same reliability as a 1000 person Chinese whisper

3. Staff turnover
You can’t stop staff turnover and you don’t want to.
Many organisations I work with have ‘someone’ who has to be retained – scarey.

* It is inevitable that staff will come and go and also that skills and experience will change
* Train your staff well and measure performance and conformity.
* Avoid the hero culture. Ensure that you apply the same principles to knowledge as you do to compute resilience i.e. N+1
* If you have critical systems with critical staffing requirements make plans to mitigate your risk. Automate, train, replace, apply staffing RAID1, RAID10

4. Corporate memory/intertia
We can’t do that because we are too large|have compliance|……
Being unprepared to make improvements because of corporate memory is just plain lazy

How often do I hear ‘You can’t do that’ or ‘that won’t work here’ or similar
* Don’t settle for laziness; create a culture to challenge convention
* Become the skeptical optimist; advocate the ‘we can do better’ approach and aim to prove it
* But don’t try and change the whole environment in one fell-swoop
* Make changes, strategically, but don’t do so without sponsorship

5. A relatively young industry
Whichever way you look at it IT/IS is a young industry; search for learnings from other sectors, specialisms. Take some of our own medicine! How many other industries has IT changed? Yet IT refuses to automate itself.

* It is surprising how little we have experimented
* It is surprising how few IT people are prepared to take risk
* Doing the same thing in the same way many times will yield the same results; if you want to change things you have to change the way you do things
* Accept learnings from others, go out and find experts – borrow their ideas

6. Old technology
The rate of change in our industry is significant and it is increasing
Don’t
assume that any new technology will solve the problems of mankind and bring peace and harmony. Containers are great but they are not heaven-sent.

* with economic controls we must accept that technology will often be old but if it meets the needs of the business it has purpose
* Accept old technology; it can still be automated – you don’t have to Dockerize everything

7. The cloak of invisibility
The number of times I hear the words ‘we don’t have any data’.
Organisations which try to make improvements without evidence should fail.
Apply the scientific principle for crying out loud.

How often do we make changes without any data?
* We tune a server, or focus on performance coding when we don’t have any indication that there is a problem or where it lies
* We state that we can reduce cost when we don’t understand what something costs today
* We over-engineer because someone decides a service must meet certain unspecified requirement
* The business does not have any defined KPI’s and therefore doesn’t know what is important to it

8. The fragile artifact
Ignore the fragile artifact at your peril.
* I spent time in the IT department of an airport once and the ground handling system was the fragile artifact.
* Go near it and it might fail – so, people didn’t go near it
* When it failed everyone kept their head down
* Stop!!! – focus on the fragile artifact; fix it, fix the process around it, fix the team supporting it or turn it off!

9. A plethora of standards
We have standardised our Windows|RDBMS|release pipeline|……..,but we are a large organisation and we have 20 standards for each……

* So you haven’t standardised at all
* You can set a baseline / single standard – standards can be extended?
* Perhaps you are in IT and your standards don’t meet the needs of the business. Collaborate – fix the problem don’t settle on a second rate fudge
* Don’t tell me you can’t standardise – you simply haven’t considered the problem properly, understood the patterns and worked out how to abstract them

0. Enterprise Architects
Enterprise architects who attend seminar, produce Visio, talk in platitudes but can’t build systems and fix technical problems themselves do not add value to the business

* I spent some time with an airline where the EA talked about his errors in selecting a certain provider only to find that the solution he had bought did not do what it claimed; if he had spent an hour trying to use the managed service before signing the approval he would have worked this out and found a better solution
* EA’s need to be helping the organisation build and manage solutions
* EA’s need to define, measure and manage standards
* EA’s need to be driving, owning and living change

Work out what technical debt is and what it mean to you – then, and only then, we can fix the problems.

Advertisements

The Right Patterns

I am committed to the ideas behind Continuous Delivery and the approach that has become known as DevOps and I want to help organisations adopt and start delivering solutions using these approaches.

I try to use common sense approaches to guide enterprises in their adoption and present the following four patterns (in order of preference) to help guide selection of the right project to kick-off their journey:

1. A Greenfield project; you may argue that you don’t have a suitable target but I challenge this as most IT departments have something, even a component, in motion at any time

2. A strategic application (service) that is based on technologies / components that are core architectural blueprints for the long-term

3. The fragile artefact; the fragile artefact is a great pattern but requires very careful consideration before you commit. What makes it fragile & is that something you can address?

4. A third-party / COTS product

Why look for these?

1. Building blocks that can be re-used; early projects need to be used as an incubator to accelerate what follows

2. They are likely to provide good ROI and reduce TCO – and that can be measured and used to improve what follows

3. The size of the change can be made to be manageable; the emphasis is ‘be realistic’

4. In conjunction with solving the core problem it is likely one will be deploy supporting capabilities and this must be achievable; success will include tackling CI, approvals, orchestration, code review, peer programming, instrumentation – solely for the selected target but with the potential to reuse

5. We will learn but also we will be less likely to be inhibited by corporate memory or corporate inertia

6. Speed. We can deliver something tangible in a reasonable time

7. The COTS project often surprises people. It is in your best interest to ensure that your suppliers deliver product in a manner that you understand and can consume; it is necessary to ensure you understand and are able to manage it in the longer-term. As a supplier I have always been receptive when a client tells me a product needs to be delivered in a certain manner and keen to help.