Never give up. Today is hard, tomorrow will be worse, but the day after tomorrow will be sunshine. Jack Ma
Douglas Adam the brilliant writer of the awesome — Hitch Hikers guide to the galaxy at times felt writing a torturous process, to the extent he wrote himself a note to pick himself up, featured in this article in the Guardian.
“Writing isn’t so bad really when you get through the worry. Forget about the worry, just press on. Don’t be embarrassed about the bad bits. Don’t strain at them,” The Hitchhiker’s Guide to the Galaxy author wrote to himself. “Writing can be good. You attack it, don’t let it attack you. You can get pleasure out of it. You can certainly do very well for yourself with it!”
Doing things we love can at times be difficult, the creative process has lows and highs. It’s during those hard times we have to remind ourselves that creating is difficult but the end product will be worth it.
Development can be torturous
There are many things which make development difficult, particularly the many occasions you are pushed out of your comfort zone and
New Integrations
Data migration being underestimated by a factor of 3
A new programming language
Impossible deadlines
Being sold as an expert on something you have never used
triaging bugs
Being measured on progress on a daily basis in public e.g. the daily standup
Not clear on the business purpose behind
Making a mistake and bug being written on your customisation and lack of testing
Development working against you, someone else code breaking yours, builds broken, services down
my personal favourite is after you have created exactly what was asked for, the customer decides they don’t want it like that and you have to spend the next day removing what you did the previous day.
Positive attitude
Development is great fun, you create something that works from a document with how they would like it to work. You bring ideas to life and create a system someone can use and in some cases make their working life better.
Attack development, get stuck into and keep trying, failing, adjusting until you make progress.
Development is a puzzle to be solved, you are going to find a way or make a way.
I will either find a way or make one — Hannibal
A positive mindset lets you take the initiative and don’t let problems happen to you, you tackle the problems. Take control and own the situation and get the advantage of being aggressive and setting the direction.
It takes considerable effort to be good at development but the reward is in what you create.
“Those who do not move, do not notice their chains” Rosa Luxemburg
Dynamics 365 professionals see every problem as something to be solved by Dynamics 365 plugin or workflow. The environment has changed and now the best solution might not need Dataverse database but just a Canvas app.
This article — Aliens in our midst made me think about how we think about solutions in Dataverse/Dynamics 365 and how new functionality can change the way we view the problem and solution.
Thoughts change the way you look at and understand life. Once your brain has been stretched it can never go back to it’s original shape and is forever changed.
We could all achieve more but choose to do less and live a life less challenged and easy.
Evolution
I have worked on many Dynamics projects Dynamics professionals thinking and architecture could needs to evolve. The solutions most Dynamics 365 professionals create are centered around Dynamics 365 functionality, solutions are anchored around around Dynamics 365.
We need to step back get to the key business requirements/objectives and view all the tools available in Azure.
Too many people are doing the same solutions they have been for the last 5 years but it’s time to use the full power and Power platform and Azure. The same thinking and approach will produce the same results.
Why .NET developers struggle with Dynamics 365 Development — BLOG LINK
When Microsoft moved to Dynamics 365 as service, hosting workflows and plugins used the Dynamics 365 service. Microsoft instead of developing this, creating Power Automate, PowerApps, Logic Apps. These can be used by Dataverse and stand alone Power Apps without a database.
For most Dynamics 365 developers, Dynamics 365 is the solution. It’s not anymore and they need to get up to speed with the tools and possibilities in Azure, AI, Power Platform.
First principles
Dynamics 365 developers should try a 1st principles approach to projects
“I think it’s important to reason from first principles rather than by analogy. The normal way we conduct our lives is we reason by analogy. [With analogy] we are doing this because it’s like something else that was done, or it is like what other people are doing. [With first principles] you boil things down to the most fundamental truths…and then reason up from there.” Elon Musk
What are the benefit of “first principles” thinking?
It allows you to innovate in clear leaps, rather than building small improvements onto something that already exists. Musk gives an example of the first automobile. While everyone else was trying to improve horse-drawn carriages, someone looked at the fundamentals of transportation and the combustion engine in order to create a car.
The first principles approach takes more energy but the solutions are more focused to the business needs.
Dynamics 365 consultants create solutions using Workflows, developers create solutions using plugins and JavaScript #HoskCodeWisdom
This is how they have been taught and what they have always done. It’s been successful in the past and will probably work in the future.
It’s a solution first, requirements second, look at alternatives if we have to way of thinking.
This thinking is a man with a hammer thinking, when you have a hammer every problem looks like a nail. The previous successful projects using workflows and plugins encouraged those developers to keep doing it.
This created difficulties when Power Automate and Azure Logic apps were first introduced. Developers were reluctant to move to Power Automate and Logic apps because they didn’t have experience in these area.
Link requirements to objectives/goals, too many projects are lead by the technology of the solution, this is because in the past technology was limited as to what could be practically delivered.
Business don’t care what technology is used to create the solution, they care the solution helps their business and helps individuals do their jobs easier.
The only limitation to the scope and breath of solutions is the knowledge of the solution architect. The barrier to an effective solution is their knowledge or the business and knowing what the purpose of the functionality is.
Projects should be business lead and solve the problems of the business, not create solutions around technology because it veers away from the business needs and takes the focus away from the business needs.
“Experience is what you get when you didn’t get what you wanted .” ― Randy Pausch
Development experienced is earned the hard way by trying, failing and trying again until you get it right.
Developing isn’t easy and anyone who says it is will soon be humbled by the process. Senior developers are expensive but inexperienced developers will cost you more with late projects. Not all experience is equal and when you get to lead developer you need standards and leadership (values which are also learnt)
Experience is what you get when development didn’t work as planned or when something goes wrong. Experience is gained by working outside your comfort zone, on areas you haven’t done before. The cost of developing is making mistakes and a slower development speed because of the trial-and-error nature of learning.
In development theory is good but practical experience gets work done. It’s not until you create code in a new language or framework that you know you can do it.
Why is development hard?
The same approach doesn’t always work every time because the requirements are unique, the people involved are unique and the solution is unique. A creative process, involving people, communication and creating functionality that needs to work individually and as a complete solution. There are unknowns that cause errors. Errors and mistakes are a part of the process, going wrong and fixing it. Feedback is the fastest way forward for the solution and the developer growing their skills. Experienced developers limit the risk of things going wrong badly. They avoid more problems and fix the problems they find quicker.
The cost of learning
New Languages and frameworks are the same and yet different. The key concepts are the same, but each has its own syntax and processes. It takes time to learn how it works and the processes around deploying, creating and debugging etc.
The cost of learning is mistakes, getting it wrong will help you understand how to get it right. This is the on boarding cost developers need to pay to gain experience. Experience allows you to avoid future mistakes. In theory there is no difference between theory and practice, no difference between knowledge and creating code and customization.
In practice there is a big knowing what to do and doing it are very different and doing it will throw many unexpected challenges. Therefore practical experience is more valuable than theoretical knowledge.
An example is IT professionals with certifications, it shows they have the knowledge but doesn’t give any sign they can use that knowledge effectively.
Project plans are based on developers working at a steady speed. If the team makes decent progress, then we deliver the functionality roughly on time.
When bigger problems arise and progress slows significantly, then projects soon fall behind. This is when leaders and customer get alarmed.
Experienced developers don’t get blocked and through experienced have learnt to tackle problems logically and find the cause. Experienced developers, slow down and ask the right questions to resolve the problem.
Experienced developer reduce the big mistakes, resolve the smaller mistakes and deliver at a consistent rate. This allows projects to be delivered on time.
Conclusion
There is no shortcut to mastery, you earn it by doing, and it’s the fastest way to learn.
Experience is valuable because until you have done something, you don’t know how difficult it is and you don’t know all the mistakes you are going to make. Experience reduces the potential for making mistakes.
“Life is not what you expect: it is made up of the most unexpected twists and turns” — Ilaiyaraaja
Projects are fertile breeding grounds for problems. Ingredients such as groups of people working to tight deadlines, using new technology/features with no experience and lots of activities happening at the same time.
Some problems go off like a hand grenade, grab everyone’s attention and demand to be resolved quickly. Other problems hide in the background, sleeping, and then when everyone is looking the other way they unexpectedly cause enormous problems.
What’s the unexpected risk that will disrupt your project?
Like being hit by a car you didn’t see, the surprise doesn’t give you time to plan or react.
The Fifth Risk
In Michael Lewis’s book the The Fifth Risk: Undoing Democract it puts forward the idea president trump is a risk manager and the government official who works in the many departments manages risk.
Lewis interviews government officials in roles such as the department of energy and asks them for their top five risks. Most people can reel of four risks quickly but when they get to the fifth, they struggle and have to do more thinking. Lewis highlights this
“And I thought, that’s the fifth. The risk you’re attending to, the risk that’s top of mind, is not likely the thing that’s going to actually kill you. The fifth risk is a scary one because it’s the thing you’re not paying attention to.”
The fifth risk is a long-term risk that with gradual mismanagement could grow into a large problem. What are the risks you aren’t expecting, what’s my fifth risk on the projects and work.
Example
It works, it works, it works, then boom it doesn’t work. these problems cosy up close to you causing you to let your guard down before they go wrong with devastating effect. No one saw the big problem until it exploded.
I have seen many ignored problems suddenly turn into a large problem. A project left on debugging on a Dynamics server, every day it would log out hundreds of lines of logs which no one looked at. This was a small problem, which someone was going to get around to fixing at some point. One day no one could create any new records in Dynamics, the problem it turned out was there was no more space on the Dynamics server because it was full of 2 years of log files no one was looking at.
The coronavirus was unexpected but so were peoples reaction. If everyone had brought the same amount of food, pasta and toilet roles as before, no one would have run out. Instead some people started buying extra, which panicked others to buying extra which resulted in empty shelves and some people who couldn’t buy any toilet roll.
“On February 1, 2003, the U.S. space shuttle Columbia disintegrated when reentering the Earth’s atmosphere, killing all seven crew memberes. Columbia broke up because a piece of foam insultation broke off during the launch and damaged the shuttle’s ability to protect itself from heat on re-entry. The problem of the foam debris was not new, but since nothing bad had happened in the past, the engineers overlooked the issue. Rather than considering the risks from the debris. NASA took the lack of problems as evidence that everything was ok.” Michael J. Mauboussin — Think Twice: Harnessing the Power of Counterintuition
The nature of these problems is they don’t initially seem worth worrying about, people overlook these problems as minor annoyances and something to clean up later when we have more time. Some problem can leave a gap open for a bigger problem to occur or the small compounding of the problem grows until it becomes a big problem.
People don’t see them coming
A common problem on IT projects is the lack of standards or lowing of standards. Initially the effect is hidden by time, the complexity of the solution gradually increases. Standards code and customisations are written consistently to drive quality.
No standards creates customisations/code in different ways, different naming. The system becomes harder to understand, taking more time to debug and extend. Every new customisation takes longer, more bugs appear, and each bug takes longer to resolve.
Eventually the cumulative build up of low quality code/customisations will result in the customer considering moving to a new supplier and rewriting the system. Death by a 1000 poor lines of code rather than one fatal bug.
Covid-19 — Coronavirus
All nations were warned of a pandemic, many did test runs and found they did poorly but few changed the infrastructure to prepare for an outbreak. When a pandemic strikes, it’s too late to prepare because it can quickly overwhelms the heath service.
The best time to fix a hole in your roof is when it’s sunny.
The shortages in PPE equipment, ventilators , testing facilities, tests could have all been prepared for. It’s time to build
The fifth risk in different areas
Projects
Relationship with the customer
Scope growing out of control
Missing requirements
Impossible deadlines
Low standards
poor leadership
technical limitations
Company — Dynamics partner
reduced sales
High churn rate/people leaving
Poor leadership/lack of engagement
No strategy to win
Behind the technology curve
Solution architect
Missing non function requirements
A solution that doesn’t work
A solution not scalable
Bottle necks
Uncontrolled scope
Your knowledge not keeping track with technical change
Developer
The project leadership
poor estimates
Technical debt
Poor requirements and missing requirement
Conclusion
The fifth risk will be the small changes which don’t seem important enough to stop. This gives them time to grow and hide, until one day a massive problem explodes and chaos ensues.
The problem that causes the most disruption is the one you didn’t expect.
Most people are expert in a few areas, get overconfident and think they are experts in everything. #HoskWisdom
It takes confidence to admit you are not an expert in all areas and you should defer to someone who is. There is no shortcut to becoming an expert, it takes years of learning, experience and practice to have a deep level of understanding on a subject. Don’t tell an expert what to do it in their area of expertise because you become an idiot who over rules experts and in the long term this doesn’t work out well.
Admit you don’t know
It takes confidence to say you don’t know and most people will go with a solution they heard from someone or seems reasonable. Few people defer to an expert and many people are afraid to ask a question which could make them look stupid, instead preferring to live without that clarification and knowledge.
“A remarkable aspect of your mental life is that you are rarely stumped … The normal state of your mind is that you have intuitive feelings and opinions about almost everything that comes your way. You like or dislike people long before you know much about them; you trust or distrust strangers without knowing why; you feel that an enterprise is bound to succeed without analyzing it.” — Daniel Kahneman
Are brain is built to function without having all the knowledge, so it’s the emphasis is on our thinking and decisions to catch the moments when we mind is moving forward with the information it has.
Catch your brain forming quick opinions and avoid over ruling experts, instead use questions to understand the strengths and weaknesses of your ideas.
Circle of competence
You are might be thinking why is this important? why should I care?
When we move outside our circle of competence, we increase the chances of mistakes and create problems for ourselves. When we stick to what we are good at, we are working in an environment that is suited to our skills, when we move out we are potentially working in an environment where we aren’t suited and don’t have the knowledge or skills to operate successfully.
Tiger Woods is great at golf but if he was challenged by a below average computer programmer to write a computer program, he would lose. If Tiger Woods opened a restaurant there is no guarantee that it would be successful because Tiger Woods is an expert in golf not cooking (that I know of). His expertise in Golf won’t help him with his restaurant.
“As they say in poker, “If you’ve been in the game 30 minutes and you don’t know who the patsy is, you’re the patsy.” — Warren Buffett
Overruling experts
It’s easy for individuals to become the patsy. I worked on an IT project where the customer put forward and insisted on a technical solution.
I mentioned that you hired us technical experts and this isn’t the solution we would recommend. The individual had worked with that technical solution in a previous company but didn’t have the knowledge of the current technical solution to know it was a bad idea.
The technical solution turned out to work slowly and later that person complained about it. We referred back to the discussion and evidence that we didn’t recommend this solution and they overruled us and took the responsibility for the decision. The end result was a change request to implement the solution we previously suggested.
You don’t know what you don’t know
A little bit of knowledge gives false confidence that we are knowledgeable in it but this is because you don’t know the detail. Experts consider decisions and a greater depth that novices don’t even consider.
“We don’t need to be amazing at everything to do high-quality work. The smartest and most successful people are often only good at a few things — or even one thing. Their secret is that they maximize those strengths and don’t get distracted. They define their circle of competence and don’t attempt things they’re not good at if there’s any room to double down further on what’s already going well.” Shane Parrish
The article quotes Gian-Carlo Rota
“mathematicians, even the very best, also rely on a few tricks which they use over and over”
Playing and managing
There are lots of world class footballers who assume their expertise in playing football and working with great managers will enable them to become a great manager themselves. The skill of playing football and managing a football team are completely different.
Playing is an individual skill — fitness, tactics, position specialization and how you as individual fit in the team
Managing is tactics, motivation, recruitment, etc. Managing is considering the team and all the people involved (not just playing staff).
Conclusion
Don’t try to be an expert in everything, understand what areas you are the expert and what areas you are not. Who in the team has more experience and knowledge in this area and ask their opinion. Are brains make it easy for us to have an opinion but we have to check it’s not leading us astray or creating problems for us.
It’s hard to admit we don’t know but you will get more respect for doing it. Saying you don’t know isn’t a sign a weakness, it’s an honest assessment that this isn’t your area of expertise and to defer to an expert in this area.
We have an edge when dealing with areas we are an expert in, when we move outside of our expertise we have no edge and shouldn’t play there.
Know where you are an expert and where you are an idiot
We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction. Bill GatesThe UK government’s response to Covid shows how easy it is to underestimate a project and how you can overestimate your effort. Project takes longer, costs more and can often fail.
IT projects underestimate effort, complexity and time (all contribute to cost), whilst overestimate the effectiveness of everyone involved and the benefits.
How do underestimate?
Low estimates are what everyone wants to hear at the start of the project. Everyone wants to hear it the project will be quick, simple, with a fixed cost and lots of benefits. The people involved will find ways to support this line of thinking
The bid is decided on cost (e.g. lowest wins), not if it covers everything.
The high level requirements are more basic than the eventual low level requirements but this scope enlargement is not factored into the plan
Leadership wants a low bid and quick estimate
The goal of the team making the bid is to get a low cost and small timeline. The initial goal is accepting a low bid not the goal of delivering the project and often the team responsible is different.
No one gets in trouble for telling someone what they want to hear. There is no incentive for team choosing the bid to accept a more detailed plan that is more likely to deliver a successful project.
I seen the process where the project bid I helped put forward was rejected for a bid that had a lower cost but missed many of the steps that I felt the project would need to be delivered successfully. It made me wonder why they didn’t ask the other bid why they didn’t have this included in their plan and it highlighted problems to me. The goal of the team accepting the bids was to get the best value for money bid not the bid most likely to deliver the project successfully.
Incentives and performance reporting influences the behaviours and choices
“Never, ever, think about something else when you should be thinking about the power of incentives.” Charlie Munger
Projects and plans
IT projects involve groups of people working together to deadlines, making quick decisions, making mistakes, replanning and creating multiple smaller systems which work together as a whole.
Projects involve customer teams/individuals doing an unfamiliar role and working to faster timelines than they are used to.
Plans are made but in projects the plans quickly go stale and our not in sync with the environment. Plans need to be updated regularly, a process most people don’t like doing because it involves telling leadership it’s going to take longer (plans never get shorter).
Why plans go wrong
It’s impossible to create a new system on paper and work out all the small details needed in the system. Why? You don’t know exactly how a system needs to work in detail at the start, you have to learn and iterate.
Initial system will have logical and technical bugs. No plans include this work because you don’t plan for the system to built incorrectly or unknown problems. This is where adding contingency is important but this is often viewed as a luxury that optimistically the planner hopes won’t happen to their project (spoiler alert — it will)
A system on paper/plan isn’t the system needed by the user. You only find this when it’s used and through feedback from using the system and trying to do their jobs.
Goals, priorities and working practices change over time, these change the order and the scope of plans.
UK government Covid response
Covid shows how easy it is to underestimate the difficulties in creating a new system or new process from scratch because we forget existing systems are built over many years of small improvements to a business process and system.
This article from the Guardian discusses what we should learn from the Covid crisis.
The article has a great quote There is reason to be sceptical about the contention that Britain would have endured a less fraught crisis if only ministers had possessed more dictatorial powers. Things for which the NHS has responsibility have generally gone very well, a notable example being the smooth implementation of the vaccination programme. Things over which politicians have direct control — such as test and trace, the provision of protective equipment, the timing of lockdowns, the enforcement of quarantining measures and border controls — have not been glittering testimonials to the speed and quality of ministerial decision-making. It is not self-evident that the best answer to the health service’s many challenges is more Matt Hancock
NHS processes
Vaccination
Emergency plans to deal with hospitals that hit capacity
Government new initiatives and systems
Track and trace
Provision of protective equipment
Lockdowns
Boarder control and quarantine
The existing NHS systems and people responded excellently because the existing and had experience and skilled people running them. The hospitals expanded to deliver care despite hospitals hitting capacity (how many businesses could do that?) and the vaccination rollout has happen at a rapid pace.
To put the vaccination rollout into perspective, it’s the fastest national vaccination in history of the UK.
The systems which didn’t work was the new ones setup because it takes more time, effort and expertise. Most importantly you need the system, processes need to be tried to get the feedback and fix the problems.
During the implementation of a large project there is a need to make quick and decisive decisions. You will need to change plans to reflect reality, when your plan needs to change due to the environment and feedback.
Communicating and leading are vital skills on large projects, you have to be able to understand and resolve problems at rapid speed in order to not lose momentum. These are not common skills and often the lack of them is the cause of projects to slowly go wrong, 1 day at a time.
The outside view
We forget the the difficulty in creating and delivering new projects, the false steps, the problems, the bugs and changes. A great way to see how long something will take is to view it with the outside view, e.g. how long did similar projects take.
Early in the Covid pandemic , there were wild timelines given for a vaccine, if you look at the long view, you could see at best it would take 18 months
Incentives cause projects to underestimated in complexity and over estimated with regards to the ability of the team to deliver them.
Unforseen problems are not taken into account because everyone wants to hear the project is going to be finished at the soonest possible time for the least amount of money.
Those who raise problems can be blamed for those problems and there is no incentive or benefit to raising problems.
There is a usually a big difference between the time we think a project will take and how long a project really takes.
Hosk's Dynamic Blog 