The word ‘COOL’ will be used to describe the latest tech hype item in the article below.
Often I see the ‘COOL’ – coding features / models, components, technology or applications being used simply cause its the latest ‘COOL’ thing around.
Beware of the ‘COOL’!
We as humans for some reason have got this believe that the latest must be the greatest and this is something that pushes our innovation and advancement but it does not come without risk.
This constant push to learn and use the latest is something that drives many software developers and if you do not keep control of it you will end up with many things considered ‘COOL’ making its way into your product. The result being a software product that resembles the chimera of ancient times.
Image from The 800-Pound Chimera
The main reasons for this is is that developers are to close to the detail and do not always see the big picture and are looking for solutions to their problems without considering the stability of the product. The software developer will also not see anything wrong with experimenting with the ‘COOL’ at the cost of the company so that it can be added to his CV. The company will inherit the cost of maintaining the new ‘COOL’ whether it is needed or not.
Yes, I have worked with this latest ‘COOL’. – add to CV.
Look out for the ‘COOL’ evangelist.
Often what happens is that the ‘COOL’ becomes a hammer and the ‘evangelist’ is ready to convince all that the ‘COOL’ can be used to solve all the problems that exists in the application or even the business.
Behold the hammer of Hephaestus. The solution to all our problems – every problem we have is a nail.
As a result of the evangelist the direction of the product is severely influenced and this is OK – if it is the direction in which the company is going.
How to control the ‘COOL’ creep.
Companies employ experts or key individuals in certain fields at great cost and these individuals must carry the responsibility for their area of expertise. Decisions on whether the ‘COOL’ should be added is the responsibility of these individuals. You need opinionated individuals taking care of the product so that it remains consistent.
Respect the knowledge and expertise of these key people and allow them to make the ‘hard’ decisions – that is what you are paying them for.
A software system should be opinionated in certain areas. process, UI, architecture, technology selection and database design are some of the key areas that is best controlled by key individuals to have consistency through a system and the development of software
Beware of making decisions by “democracy” or “mob”where everyone on the team has an opinion, you may be going down a dark path. A knowledgeable person that has gained the experience or education of why something should be done a certain way can easily be out voted by others in the team.
Companies often flatten the management structures to try and make everyone feel like they have a say but the reality is that you need key people with strong opinions in certain areas. The key individual can listen to the opinions of the team but in the end it should be his \ her decision and he can explain why he made a certain decision and it should be respected.
- The CTO guards the process of R & D within the Software development house.
- A UI Expert should be employed to keep the look and feel of the software consistent.
- The team lead should control the ‘COOL’ within the project and source.
- If the ‘COOL’ is introduced by the team lead himself he needs to be reviewed by a peer.
- A database expert should be used for the structure and indexes of your database. This is where your data is stored and where much of a system speed comes from. Is should be treated with respect.
- The architect is the guardian of the the big picture and he will have to guard against ‘COOL’ creep in the big picture.
Consider the risk of the ‘COOL!
Before allowing the ‘COOL, make sure the following is answered and checked.
- Does it fit the use case?
- Are we using it for the correct reasons?
- Does it fit in with where the company is going?
- Do we need it right now?
- Do we need to write our own ‘COOL’ or can we purchase one reducing our own risk?
- What is the impact of implementing the ‘COOL’?
- Does the rest of the application, especially infrastructure and frameworks work with the new ‘COOL’?
- How mature is the ‘COOL’?
- Has a realistic POC been done with the ‘COOL’?
Before adding anything new to a stable product make sure of the risk involved. We live in a time where security risks are everywhere and it is best to be reluctant when it comes to upgrading to the latest ‘COOL’ as it brings its own set of new problems.
Be careful, as the ‘COOL’ can cost you weeks of unplanned R & D.