It’s been a while since I did not write anything. There’s a good reason for that: I’ve been busy trying to understand a new business (derivatives in general, specifically derivatives margin computation). I left my comfort zone so I had to learn a lot about financial domain and mechanism.
I inherited a project context that needed healing at many levels. I’m not allowed to share the specifics but more than ever, the following recommendations applied to the project context.
Depending on your company and what its information system (on the broader sense) suffers from, you might want to take different actions. But I suspect the following piece of advice won’t harm:
- Invest in training and research
Accurately understand your process and your business. More importantly, make sure that not less than 80% of your collaborators know about that business at a satisfying level. It helps being on the same page. When you understand the problem you are more likely to find wise solutions. Take the time to provide simple, accurate documentation. Provide internal trainings. Newcomers should first understand the business before trying to improve it with external trainings. Take the time to gather various feedbacks and to analyze them. Most of the time various problems share a common cause.
- Provide a plan to improve
Hire a smart collaborator to provide and share the common vision: smart does not necessarily mean the most technically skilled. Most of the time it’s not the most technically skilled but a collaborator who can tackle the problems from the right perspective and perfectly leverage his team members skills. He must understand them and be methodical. Once done, he will come up with a plan, a vision and steps to reach the goal.
Provide time framed objectives: “By september of 2015 all application should be migrated to Awesome FWK 2.0. Consequently OLD FWK should be decommissioned by then”. It keeps people motivated for longer goals.
Provide one big goal per year and steps to achieve them: “This year we will build a continuous delivery framework. The year after all new applications will use it. The year after all legacy application should also use it”.
- Hire smart and skilled collaborators
It’s better to have few highly skilled collaborators than an army of inexperienced ones. I can’t stress out less that requirement: it’s at the heart of your success
Also don’t be in a hurry to choose the collaborators. Take your time. By carefully choosing your collaborators both candidates and teams will thank you: they are more likely to build something on the long term.
- Make it simple
Simplicity is the ultimate sophistication (Leonardo Da Vinci): it takes a lot of skills and work to transform a complex concept into something accessible to the majority. It also requires skill to extract the essence out of it and remove peripheral noise. Think of all the complex products we use on a daily basis that remarkably abstact complexity for the user’s sake. They require several areas of expertise (cars, ATM, planes) yet all this knowledge is hidden to us: this is sophistication, not the other way around. Think of Whatsapp: very simple feaures but an impressive backend infrastructure.
Divide and conquer: break the complex problem into dozen of simpler ones. Think of Git: many simple tools that don’t do much but do it remarkably well.
- Iterate
Simple concept yet powerful. Worst case scenario: you realize after a few iterations that you are on the wrong path. You can either abort or rectify.
Many projects owe their success solely to that very principle. It’s an excellent risk management practice.
The idea is so powerful that it has been borrowed many times in software industry:
- Make it work, make it right, make it fast
- Minimum viable product
- Test, code, refactor
- Baby steps
- Plan do check adjust (PDCA)
- Make it extensible and maintainable
Change and evolution is a natural process. Why fight it ? It’s a common mistake to limit the cost of a software only to its “build/construction” phase. Actually most of its cost is attributable to its evolution stage during which it frequently needs to integrate new constraints, new features while still supporting all previous ones. Without extension in mind the evolution is really costly and painful.
Track down duplication: at class level, package level, module level, application level, component level. You’ll get a stable as well as cohesive information system.
Duplication weakens your reliability and your cohesion because its generates synchronisation overhead and most of the time double verification. It really has a cost
Separation of concerns/responsibilities is the fundamental design principle that will make your software sustainable and extensible in time.
That principle, pushed at organizational level, led to a “not so new lately” architetural style: Micro services.
- Make it predictable
Test (not going to elaborate on that obvious one)
Automate
- Let your IT team concentrate on the process and the business, not on time consuming and error prone technical tasks: automate as often as possible. If a process is automated the teams will have time to improve it, evolve it, refine as close as possible to business needs.
- People often make the mistake to think that automation threatens their job. Allow me to strongly doubt that belief. A business process can not improve by itself, neither can an automation process keep itself in sync with the business process. Both need human brains to refine, polish and evolve.
Diving deep into JEE 