one simple tip to improve you development and project estimates

It isn’t just developer who underestimate tasks, it’s everyone and it’s all the time #HoskWisdom

When we estimate tasks, we underestimate the time it takes because we overestimate our abilities and believe our future involves fewer problems. Most estimates assume no problems, mistakes, other activities will distract us. Using the outside view (similar examples), can help avoid this bias.

This problem is not confined to developers, a common example is people underestimating how long it takes to commute to work and who are late.

Why do developers under estimate?

Happy path estimate — no meetings, problems or any other activities will impede development

There is an unwritten rule when asking a developer to estimate how long it will take, add at least 25 percent onto the estimate or 50 percent if it’s complex. I have seen spreadsheets used with a column for confidence or unknown as a percentage. This column is then used to multiple their estimate and get towards a more accurate estimate.

You are probably thinking this sounds like padding or giving extra time but consider how many times you managed to do a task without the following happening

  • Being interrupted
  • Finding extra tasks missed in your original estimate
  • Extra requirements or scope increasing
  • A technical problem
  • Finding problems in other peoples code
  • User error, adding bugs
  • Someone asked you a question or for help on a different problem
  • A meeting over running or a new meeting arranged
  • unforeseen consequences of other functionality or the whole solution

There is pressure to estimate low from the manager, the customer and the project plan.

If life was perfect, we would get the task, know everything about it, find a quiet place, do the work with no distractions. 99% of the time that happy path doesn’t happen and other activities not on the plan slow us down.

Estimates are not commitments, they are a guide to how long we think a task will take. I have seen developers 99% finished on a piece of development and the last 1% take as long as the first 99% 🙂

Everyone overestimates

“The reason is most people think of themselves as different, and better, than those around them” Daniel Gilbert

We have an above average view of our abilities. If you ask a developer if they are an above average developer, most will reply yes.

Answer yes or no to the questions below

  • I am an above average developer
  • I am an above average driver
  • my intelligence is above average
  • I am better than most at picking films to watch

If you answer yes to 3 or 4 of those you believe you are above average but statistically you are average. We believe we are above average and because we are doing it, it will go better. We overestimate how fast we will complete the work.

Another contributing factor is known as the illusion of optimism, we believe good events are more likely and bad events like likely to us. The larger the he task the greater the chance of delays.

The inside view

Making predictions using the inside view is to estimate how long a task will take using the information we have, our understanding of the problem and solution. The brain allows us to to do this fast and make an estimate we believe is accurate.

Making predictions using the inside view risks missing complexity we hadn’t considered or ignored.

The outside view is to consider the task based on statistics or how long it took similar tasks (not the estimate).

Daniel Kahneman gives an example where he and a group of people set out to write a curriculum text book, the group estimate was 2 years. When Kahneman asked a member of the team who was a curriculum expert (who had seen many text books created), how long it took other teams to create a curriculum text book the answer was different (see the quote below)

He fell silent. When he finally spoke, it seemed to me that he was blushing, embarrassed by his own answer: “You know, I never realized this before, but in fact not all the teams at a stage comparable to ours ever did complete their task. A substantial fraction of the teams ended up failing to finish the job.”

This was worrisome; we had never considered the possibility that we might fail. My anxiety rising, I asked how large he estimated that fraction was. “About 40 percent,” he said. By now, a pall of gloom was falling over the room.

“Those who finished, how long did it take them?”

“I cannot think of any group that finished in less than seven years,” Seymour said, “nor any that took more than ten.”

I grasped at a straw: “When you compare our skills and resources to those of the other groups, how good are we? How would you rank us in comparison with these teams?”

Seymour did not hesitate long this time.

“We’re below average,” he said, “but not by much.”

The story is from here Daniel Kahneman: Beware the ‘inside view’ and is an excerpt from the book Thinking, Fast and Slow. It highlights how the inside view can underestimate the time it will take and the outside view can give you an unbiased estimate.

You can watch a video of Daniel Kahneman describing this process here

Can you guess how long it took to create the book? The group (inside view) estimate was 2 years, the outside view between the minimum 7 years — maximum 10 years.

It took 8 years, 4 times the groups original estimate and within the range predicted by the outside view.

How to overcome this?

We are optimistic about our own abilities and estimates of how long it would take us but we are more accurate if we estimate how long it would take someone else (.e.g. an average person).

When you have estimated some work, get another developer to estimate how long they think you would take to do it or ask them how long it took them to do it on a different project.

Compare the estimates of similar developments on other projects or on your project. The time took to do similar developments is devoid of bias and will give you a base rate.

We think we are different and our project is different but they aren’t, so it get an outside view from someone who can step back from the project and asses it analytically.

Other reading


How inverting problems can help you become a better software engineer

“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” Charlie Munger
Not being an idiot is more effective than being a genius in most situations #HoskWisdom

The default approach is to find solutions to problems but instead of solutions to problems, invert the problem and stop doing things which make it worse.

Sometimes the best way to solve a problem is to avoid it and don’t waste time and effort on working on the wrong thing or heading in the wrong direction.


When software engineers start their career they suck, they have little knowledge, few skills, zero experience but lots of enthusiasm. Every task is hard because they don’t know how to do it, they don’t have the skills or experience.  Junior developers make mistakes and need help from their senior colleges.


Improve skills, knowledge and experience

Inverted Goal

Stop making mistakes (and slowing improvement)

The goal of a software engineer is to get better, by doing

  • Learn new skills
  • Gain knowledge
  • Write code
  • Make mistakes and learn
  • Watch videos

What if we invert the goal, instead of focusing on being good, the junior developer focuses on avoiding mistakes and getting worse.

  • Code analyser to catch bad code
  • Learn from mistakes and make sure you don’t repeat them
  • Get code reviews to catch badly written code

Avoiding mistakes allows new software engineer to pick up momentum and replace bad behaviors with good behaviours.  Doing stupid things slows your momentum because you need to undo the wrong action before you can move on to doing the right thing (warning, you don’t always know what the right thing is).

Avoid being stupid and doing stupid things instead of focusing on doing clever things.  Experience developers make fewer mistakes because they have learnt to avoid them, this results in steady progress which scrum masters and project managers love.

Improve by not making mistakes

Don’t  limit you stuff to just improving but focus on avoiding mistakes #HoskWisdom

The British cycling team lead by Dave Brailsford use this method to improve with marginal gains by looking for lots of small improvements.

How 1% Performance Improvements Led to Olympic Gold


Help the riders recuperate and get a good nights sleep

Inverted Goal

Stop the riders from having poor nights sleep

They wanted to improve the sleep of the riders when they sleep in hotels in unfamiliar surroundings and different beds.  To improve the sleep of the riders they inverted the problem by looking at what was making the sleep of the riders worse.  To improve the sleep the Sky team brought the riders own pillows to each hotel.  This improved the sleep by not making it worse.


Inversion is used in code analyzers to improve the quality of code and teach developers to write better code.


The goal of code analyzers is to help developers create quality code

Inverted Goal

Stop developers from writing poor quality code

Code analyzer has rules, containing examples of bad code.  Developer runs the code analyzer it finds examples of bad code and raises a warning.  The developer fixes the problem, swapping poor quality code for better code.

Writing good code is avoiding writing bad code, swap bad habits for good habits and beat the suck.

We can use the approach to projects and the method to speeding up the project is avoiding slowing it down and targeting the bottle necks and processes which take a long time.

Making a project faster is avoiding slowing it down #HoskCodeWisdom

Bug fixing

We use inverted thinking many times as a developer and bug fixing is a good example.


The goal bug fixing is to find the problem and fix it

Inverted Goal

Confirm what works and narrow the causes of the bug

When bug fixing, forget what you think is causing the bug and prove what works to narrow the search for the problem.  Inverting the problem helps you rule out the working functionality.


The goal of football is to win matches but for the teams in the lower half of the premier league they should invert this and make the goal to not lose matches.

Scoring goals is difficult and goal scorers, creative players cost more money and the lower teams cannot afford top strikers on their budgets.  If they focused their recruitment and training in not conceding goals, not making mistakes and trying to convert set pieces they have a higher chance of success.

Experienced managers such as Sam Allardyce, Tony Pulis successfully use this tactic by focusing on not losing.  Don’t lose the match and hope to win.  The opposition will make a mistake, your player will score an amazing goal or you convert a set piece.

If you don’t let a goal in, you can’t lose the match.

This article highlights the  difference between professional tennis players

Professionals win points where as amateurs lose them


Inverting problems helps you view a problems from different perspectives so you create incremental improvements.  Inverting the problem is a thinking tool to create innovative solutions and different solutions.Time spent thinking about a problem is time well spent.

Analyse the problem, invert the problem, come up with lots of solutions before picking the best one.  Make your plan and focus on execution. You can save time but avoiding mistakes or executing the wrong plan.

Following the wrong plan is heading off in the wrong direction to your destination.

I will end with this quote from Charlie Munger


Invert, always invert: Turn a situation or problem upside down. Look at it backward. What happens if all our plans go wrong? Where don’t we want to go, and how do you get there? Instead of looking for success, make a list of how to fail instead – through sloth, envy, resentment, self-pity, entitlement, all the mental habits of self-defeat. Avoid these qualities and you will succeed. Tell me where I’m going to die, that is, so I don’t go there. – Charlie Munger

Further reading

Are you a Dynamics Craftsman or a CRM developer?

“Don’t comment bad code—rewrite it.” ― Brian W. Kernighan, The Elements of Programming Style

The quality of your work is related to the standards you set yourself #HoskWisdom


A few months ago I joined Capgemini and people have been asking me what attracted me to join the Capgemini CRM team and what it‘s like to work for Capgemini.  What attracted me is Capgemini’s want to bring software development principles to Dynamics CRM development and focusing on delivering quality enterprise Dynamics CRM/365 projects.

What I really like is Capgemini Dynamics CRM projects have DevOps who setup automated deployments, Continuous integration,  one of the greatest gifts to dynamics developer because it allows more time in creating customisation

Are you a Craftsman?

When interviewing developers I like to ask them if they are Craftsmen or developers, this question finds if the person being interviewed is driving the quality of their work, if they have pride in what they are creating.

Creating quality code like motivation comes from within and can’t be forced using standards or rules.

Dynamics developers need passion – CRM Developers need Passion and joining Capgemini is a good fit because we shared many beliefs.

It‘s importance to keep the quality of CRM projects high and manage technical debt, these principles are even more important on large projects where poor quality code can slow the project and maintaining code can become a nightmare.

I experienced a project where it took 1 day to add an easy fix because a plugin had one method with 2000 lines of code

I can recommend the book

I recommend a few other books in the post – Why isn’t code reused in Microsoft Dynamic CRM projects?

My experience of CRM development

I started out as a Java developer and learnt traditional programmer principles.  Learning about programming and I remember being iinspired by code craftsman and reading Effective Java : Second EditionHead First Design Patterns, Object orientation programming and other books listed on Recommended Books for Developers.

There was a story about a developer learning to become a craftsman, it was featured in a magazine and was a regular column. It talked sbout problems newbie programmers walk into without realising.  (it was called something like the woodcutter or craftsman)

When I moved from Java/.netdevelopment it seemed many CRM development companies didn’t follow good software development practices or good coding standards.

  • CRM code often put all the code into one method in the plugin
  • Lack of classes
  • No unit testing
  • No automated builds
  • No code reviews or static analysis

There are a few reasons for this

  • Microsoft Dynamics CRM made it difficult for automated builds (before solution packager)
  • Companies were not interested in invested in
  • Many CRM projects were small with no budget for automated builds and unit testing
  • CRM developers often didn’t have programming experience or knowledge of SOLID principles
  • Timescales were short in projects – focus on short term gains

Dynamics CRM and developer principles

When I interviewed with Capgemini they wanted to know my opinions on unit testing, code quality.

Capgemini wants to bring software developer principles to CRM but what does this mean?

Capgemini CRM projects are big enterprise integration projects where code quality is important when creating lots of code, which means you will be maintaining lots of code.

Enterprise projects are long projects, technical debt must be kept low and members of the development team adhere to high standards (high standards are a habit)  Here are some of the methods we use to keep quality high

  • CRM DevOps help developers do their jobs
  • Automated deployments/CI environment
  • Solution packager can import data
  • Solution packager splits up customisations to XML file and stored in source control
  • Code check ins to master have to be reviewed and accepted by senior developers
  • Static analysis on code
  • Static analysis errors and warnings must be removed
  • Capgemini hire good Dynamics developers and make them better (join us here)
  • Minimum 90 percent unit test coverage on Business logic code
  • The Quality code message comes from the top
  • The standards implemented on a Capgemini Dynamics project are higher than developers implemented

Regrets I have a few

After working on a project with automated deployments I think this should be a priority for all Dynamics projects to setup on a project, it offers so many benefits which I discuss in the post below

CRM 2016 – Release management, Solution packager and why you should automate your deployment

I wish I had pushed for higher quality on Dynamics projects I had worked on earlier in my career because if you are not writing high quality code you are adding to the technical debt of a project.  I have seen many Dynamics CRM projects start adding technical debt straight from the first line of code because they used poor standards and practices, these projects get harder and harder

It’s great to work on a Dynamics CRM project using software principles.

Capgemini aim to take good CRM developers and make them better by delivering hard projects with well crafted solutions

You can join the Hosk at Capgemini by applying here

Why developers should use code analysis to keep code quality high

Programming is like sex. One mistake and you have to support it for the rest of your life. Michael Sinz


The battle against bad code is a never-ending one and it’s important CRM developers keep code quality high.

These blogs talk about the effects of bad code

One of the causes of bad code is rushed projects and tight deadlines, developers need to have integrity and not let leave a CRM developers stranded.  You can stop bad code by writing code like a boy scout and having passion for CRM development

It takes effort from all developers to keep code quality high, developers need to refactor their code and peer review the code of junior developers.  If the code is a high standard, developers will check in high quality code but as soon as poor quality code is in the source repository other developers will think it’s OK.
CRM developers should monitor code to make sure it’s of a high quality and all companies should have and implement coding standards document.
CRM developers should use static analysis tools to check their code as part of the process of checking code into source control.
To keep code quality high you should
  • Write unit tests
  • Use static analysis tools
  • Code reviews
CRM developers should write unit tests and review their code using static analysis tools like FXCop, StyleCop, Resharper, Visual studio static analysis.
  • Get into good habits
  • Junior developers learn correct formatting
  • Create quality code
  • You will thank yourself in the future
  • It reminds all developers to tidy up their code

Re-Sharper is a great tool and once you have tried it, it’s difficult to go back – CRM Developers tools of the trade – Resharper

Writing unit tests and checking and correctly your code using code analysis tools seem like extra work which one reason developers don’t like using them but it allows you test the logic of your code and for all developers to refactor the code and test if it’s still working.

Writing unit tests and analyzing and fixing code seems like you are not progressing because you are not writing new code but you are creating quality code and quality code will take less time to interact with in the future.

Bug fixing, understanding, extending and modifying is easier and quicker with quality code than it is in legacy code.  If the code is consistent between different programmers it’s easier to read and maintain –  Why your CRM code and customizations should be simple.  Static code analysis helps to make sure all code written but different developers conforms to the same standards and is similar.

A good example is bug fixing legacy code with huge methods, it’s difficult to understand and tricky to fix, Are your CRM plugins creating technical debt?


When you first analyse your code

When you first analyse you code you will get a lot of warnings and I mean lots.  If you run the analyser on a legacy project or project with a lot of code (and hasn’t been analysed before) you will get a lot of warnings.

My advice is to start small and just use this on the code you have been recently creating/changing.

Don’t take the warnings personally, view the warnings like someone code reviewing your code and giving your tips on how to create better code.

Remember they are warnings, you should see them as recommendations, in some situations is OK to ignore a warning if you have a good reason for it, this is better than not knowing there was a potential problem.

My Experience

I am a continuous learner, I like learning, I like improving and getting feedback on your code is a good way to learn, I believe in continuous learning and improvement.

Finish work a litter wiser about CRM than you when you started work.  – Hosk

When I analysed the code I got lots of warnings but I found these interesting.  I wanted to know the logic behind the warning.

It’s easy to be initially overwhelmed and condemn the analysis as being too pedantic.  In some recommendations it can be but if you can prove your reason for ignoring the warning (with something more than I can’t be bothered to change it).

Over time I found myself writing code which I knew would not generate complaints from the static analysis tool because I didn’t want to have to go through the code and correcting it.  This shows me static analysis is an effective tool in changing my the syntax of the code I was writing.

The goal of static analysis

Creating standard code syntax and get the team to deliver a minimum standard of code.  Developers can get lazy and like to quickly check in code, running static analysis is a good tool to nudge developers to tidy up their code.  Static analysis is like running a spell and grammar check on your code, it finds areas you can polish your first draft.

Static code analysis also finds common bad coding practices and highlights poor code design.

Look at the default areas the default rule set checks

  • Design
  • Globalization
  • Interoperability
  • Maintainability
  • Naming
  • Performance
  • Portability
  • Reliability
  • Security
  • Usage
  • Native
  • Errors

I had some errors telling me to hide public variables.

CA1002 – Do Not expose generic List

CA1822 – Mark members as static

 Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit nonvirtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.


Why was I getting this error, this articles help to explain

CA1822 Code Analysis warning

Can anyone explain the purpose and resolution of CA1822 on a Controller Action?

It’s ok to ignore some errors

I was getting an error CA1011 – Consider passing base types as parameters

I was passing in an early bound type e.g. contact and it was saying I could pass in entity.  I’m happy to ignore this warning for CRM early bound classes because I the method needs a contact record and isn’t going to work with a different one.  I want this type checking on the method.

What did I make of it

I found the process interesting.  As I went through the warnings I would think about the design of the code and the merits the warning and suggested action.

The key to making this productive is to understand why it’s warning you.  To do this I had to paste the warning into the internet and search for blog posts or usually forum posts discussing the warning.

Most of the warnings made me change the code for the better, it made me think about what the code was doing.  Its tedious to begin with because there are lots of errors but over time the number of errors reduces and you code becomes more standard and following best practices.

Given time I would recommend a CRM development team keep updating the rules and turning off the ones which aren’t relevant.  This would generate a set of standard rules your code should follow.


I think all CRM developers should have static code analysis running on their code, it will help you keep your code tidy and uniform.

CRM development teams should spend time updating the rules run for CRM code and turning off the rules which are not relevant.  If you had time it’s possible to create new rules.

Developers should run static analysis on their code and I would recommend all code goes through a code review, the threat of a code review will help ensure code is kept at a high level.

Code reviews are a great way for junior developers to learn from senior developers.

Further reading

What is a static analysis tool

Using Rule Sets to Group Code Analysis Rules

Analyzing Managed Code Quality by Using Code Analysis

Improving Quality with Visual Studio Diagnostic Tools

Code Metrics Values

Why isn’t code reused in Microsoft Dynamic CRM projects?

Microsoft Dynamic CRM code and customizations are rarely reused between projects and few companies create solutions to share between projects. This means CRM companies need to rewrite the same code again for each project but is there an alternative method.

CRM projects focus on delivering solutions but don’t to reuse solution and code.  In many companies CRM developers can create different versions of the same solution.

When developers work on projects they are focused on delivering a solution to meet the customers requirements.  If time the developer will

  • Improve code design
  • Refactor code
  • Reduce technical debt
  • Unit test code
  • Update documentation

The tasks mentioned focus on long term benefits and the reason they are often omitted.  Improving code design and refactoring make code easy to understand, extend, debug and maintain, these steps are unnecessary but make a huge different in maintaining the code.

The difference between good and average CRM developers can’t be seen in functionality delivered to the customer because they will be the same.

This posts

Why your CRM code and customizations should be simple

The problems with complex code and complex CRM Customizations

It’s difficult to simply code, refactor and improve the design, a reason average developers omit those steps.  Explained beautifull by Martin Fowler

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

Simple code reduces time spent debugging, maintaining, understanding and interacting with the code e.g. further phases of development.  This explains why failures in CRM projects often occur after the first release of a CRM solution when the CRM developers struggle with a messy solution.

Other signs you CRM project is doomed can be found in this article 13 signs your CRM project is doomed

I have worked on a project where a plugin had a method which was over 1000 lines long.  This method became a bottleneck in the project because developers struggled to understand what it did or how it worked.  Small changes took hours whilst developers tried to understand the code, work out where to put their fix and testing the fix hadn’t broken existing code was impossible because the code was to complex to unit test.

Custom code

Most CRM projects will have custom entities which exist only in the individual project to either make the customers business processes or needed to deliver the required functionality.

Writing bespoke projects often preclude the project code and customizations being reused because the customers requirements are not needed in other projects.

CRM developers who don’t use solid principles to reduce coupling in their code are unlikely to be able to reuse code.

Code cannot always be be reused because of unique requirements, most of the time CRM developers don’t think about reusing the code or writing it to enable reuse.

New project, new code

Before software can be reusable it first has to be usable.”
– Ralph Johnson (computer scientist)

Reusing code is a great, you can add code which has already been written and tested.  It takes more effort to write reusable code, to write code in a generic way ensuring there are no dependencies on the current project.

Developers are not rewarded for code reuse or encouraged to write reusable code and customization’s by their employers.  Without motivation or reward why would developers go to the extra effort of writing code which benefits developers/company in the long term?

To write of reusable code you need skilled developers, sometimes called craftsman.  Highly skilled developers, take pride in their work and consider long-term implications of their code and who look to reuse code.

Most CRM projects are run with short-term goals in mind, answer these questions about Microsoft Dynamics CRM projects you have worked on?

  • How often do CRM developers reuse code from earlier projects?
  • Do CRM developers know what earlier projects did to understand if any of the code or customizations could be reused?
  • How many projects is the code good enough to be reused?
  • Does anyone look at previous projects to see if they could create a generic reusable project?

Companies don’t reuse code or catalog CRM projects.  CRM professions and CRM developers move companies often, most existing and new developers didn’t work on earlier projects and are ignorant of them.

Interaction with historic projects usually occurs when a bug is raised or through a change request.  If you are unluckily enough to be dragged into an old project, they are legacy projects with code and customizations arranged in a baffling structure taking days to decipher even the simplest of bugs.

Is there another way?

Wouldn’t it be great if new CRM projects were created by plugging together small separate solutions.  It would be quicker to create solutions like this and the code would have already been tested.

CRM developers could look at old projects for common functionality that could be reused in different projects.

Identifying functionality which could converted into a generic reusable solutionIf the solution was useful it could be sold but at a least it could speed up development on new projects needing that functionality.

This would involve taking a long term view of CRM development and ensuring their CRM developers are writing quality code and customizations.

Why doesn’t code get reused

Code reuse has many advantages but I haven’t seen any examples of code reuse in the projects I have worked on. I have listed some potential reasons for this below


A lot of developers don’t love writing code and to them it’s just a job, this shows in the quality of their code.  They are not passionate about it and certainly wouldn’t classify themselves as craftsman.  I don’t enjoy decorating, I take shortcuts and aim to paint a room as fast as possible.  The lack of enthusiasm and passion for decorating the room, shows in the finished product, I spot bits I missed and drip marks.

The same result can happens with the code of people who don’t enjoy developing,

To write simple code you will have need to want to improve, the best way is to have a mentor but you can get a paper/electronic mentor by reading classic books on programming or have a mentor to teach you.  I recommend

CRM companies have s high churn rate, offering small payment increases to staff based on their current salary.  LinkedIn pressures this model with recruitment agencies offering CRM professionals the current market rate for their skills and experience, more than the current salary plus inflation.

The regular movement of CRM developers leads to a lack of long term thinking and planning.  Why write code with long term benefit if you are not going to be there to gain from it.

Development standards and way of working need a consistent workforce to implement and developers adhere to them.

Project view

CRM solution providers organise effort at a project level, gearing everything around projects.   The approach is understandable because customers pay for projects and effort is focused on money.

Creating reusable code and solutions is an activity which needs to be done around or outside of delivering a project.  It may involve going back and identifying reusable/generic solutions or taking a little bit longer to write reusable code.

Maturity of Microsoft Dynamics CRM

I’m not sure about this but I wonder if creating reusable code/solutions is something which will occur with maturity of companies and developers.

Will companies get tired of recreating everything on each project?


Microsoft Dynamics CRM currently has a major release every year, this adds a significant challenge to creating reusable solutions and code.

A solution created today could become standard functionality in the next release of Microsoft Dynamics CRM or your solution might not work, with a need to upgrade the solution to be compatible with the new versions of Microsoft Dynamics CRM.

Microsoft Dynamics CRM online is increasing in popularity, CRM online projects use a different architecture than CRM on premise.  This provides a barrier to reusable CRM on premise solutions because those solutions won’t work with the limitations of CRM online.

The long term view I have is CRM providers will create micro services in azure which will integrate with CRM online services, this architecture allows one service to be used on many CRM Online projects.  This architecture model is being used by FieldOne and their autorouting service, which is hosted in Azure.

Size of CRM companies

Small CRM solution providers whose model doesn’t afford to spend time on non project work.  Bigger companies should have an advantage over smaller companies by creating resusable code and solutions but I’m not sure many larger CRM companies do this at the moment.


It’s easy to point out the problem of lack of code reuse, it’s harder to pinpoint the steps to overcome this.

The CRM project mentality creates project focused code, not reusable or often known about by other developers in a company.

Why understanding abstractions can help you write better code

I have been a developer for many years, working with APL, Java, Javascript and C# and I considered myself a decent programmer (doesn’t everyone?)

I had read articles on the S.O.L.I.D principles

I had a decent grasp of OO design principles and understanding Polymorphism, encapsulation, abstraction and inheritance.

I used interfaces and abstract classes but it was only recently that I understood some of the benefits of abstraction with regards to code design.

This  understanding has come through reading (re-reading in some instances) various parts of the book mentioned below

  • Code Complete 2
  • Clean Code
  • Head First Design Patterns
  • Design Patterns – Elements of Reusable Object-Orientated Software
  • S.O.L.I.D design principles

Head First Design Patterns mention these design principles, which I found really useful to understand the effects of good OO design

  • Encapsulate what varies
  • Favour composition over inheritance
  • Program to interfaces, not to implementations
  • Strive for loosely coupled design between objects that interact
  • Depend upon abstractions. Do not depend upon concrete classes

Knowledge is like a jigsaw puzzle

I had read some of the material a long time ago, on my recent reading I found my initial understanding of some of the concepts was lacking a bit of understanding.  This isn’t unusual when trying to understand complex and abstract concepts, here is an interesting article on that phenomenon.

When learning new ideas and concepts you can get a partial understanding where bits of it are clear, whilst other areas can be fuzzy.  I view information/ideas as having a 3D property where it suddenly makes sense when you view the information/idea from a different perspective.

This article talks about the metaphor as knowledge as a jigsaw puzzle

Your understanding grows as more pieces of the puzzle fall into place

What is Abstraction?

Before looking at abstraction from a coding point of view what is a general definition of abstraction, Wiki has a few definition

Abstraction in its main sense is a conceptual process by which general rules and concepts are derived from the usage and classification of specific examples, literal (“real” or “concrete”) signifiers

Conceptual abstractions may be formed by filtering the information content of a concept or an observable phenomenon, selecting only the aspects which are relevant for a particular purpose. For example, abstracting a leather soccer ball to the more general idea of a ball selects only the information on general ball attributes and behavior, eliminating the other characteristics of that particular ball

Abstraction – Computer Science

In computer scienceabstraction is a technique for managing complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level

When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called polymorphism. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called delegation orinheritance.


Code Complete 2 gives a clear definition of what an abstraction is

abstraction is the ability to view a complex operation in a simplified form.  A class interface provides an abstraction of the implementation that’s hidden behind the interface

What is an abstraction?

Abstractions are used regularly in everyday language, we use abstraction when talking about lots of things, such as
  • Chair
  • Table
  • Computer
  • Mobile Phone
These are abstract ideas which everyone understands but people don’t have a mobile phone, they have an exact make of mobile phone but most people don’t talk about the exact type by the abstract type of mobile phone.
Mobile phones have some core data
  • Ringer
  • Screen
  • buttons
  • Mic
  • Speaker
A mobile phone would be a good case for a Abstract class which could be inherited by a real instance which may add more features.

Why is understanding Abstraction important

Abstractions help hide concrete code which can change with abstractions such as interfaces and abstract classes which are less likely to change.

Using abstraction limits dependencies in code, reduced dependency means reducing the effect of change in your code.

Two of the key long term goals for developers when writing code

  1. Increase the readability of the code
  2. Minimise dependencies in code, reducing the effects of change

The two goals will make maintaining the code easier, below I talk how abstraction can help you to achieve those goals.

Junior developers seem reluctant to use abstractions in code because of a mixture of not understanding how abstractions work and because they are focused on getting the code working and bypass the creation of abstractions, which can lead to big complex methods, few classes and no abstractions.

Junior developers are focused on the short term goal of getting the code working with the intent of leaving the design and creation of abstractions until later (later often doesn’t come).

Which leads me to write articles like the two below


Understanding Abstraction

Abstraction is one of the key principles behind many of the OO design principles such as

  • Inheritance
  • Polymorphism
  • Composition
  • Benefits of abstraction
  • Code is easy to understand
  • Manages change and the effect of chnage
  • Creates cohesive code – it finds common fields
  • Create loose coupling

Abstraction refines concepts to their core values, stripping away ideas to the fundamentals of the abstract idea.  It leaves the common details of an idea.

Abstractions make it easier to understand code because it concentrates on core features/actions and not on the small details.

My understanding started to grow whilst reading these two OO design principle

  • Encapsulate what varies
  • Program to interfaces, not to implementations.

The various books and articles concentrated on the benefits of these two design principles I start to understand how abstraction could reduce dependences and the affect of changes on code, you can see I started thinking about whilst writing this article Information Hiding.

How to find abstractions?

In the blog post  How to find classes I talked about how to find classes, finding abstractions is a similar exercise.  Common abstractions are
  • Nouns – things, people, systems
  • Verbs
  • Types
  • Behaviours
  • Is A – Inheritance
  • Has A – Behaviours

Actions/Verbs are often abstractions e.g. Drawing, validating, processing, routing.

When I mention types I am referring to

Abstractions are useful in life

People use abstractions all the time, you often mention 

  • Computers
  • Chairs
  • People
  • Cars

You don’t talk about the distinctive type of car but say car in general and people will understand you what you are talking about.

The same idea can be used in your code design.  You can find a common action like validating, drawing, Updating, exceptions.  The common action will be the interface and the concrete classes can hide behind it.

Exceptions are a good example you have a core exception (the ones lazy programmers throw when they don’t want to specify the exact error) and then distinctive exceptions extend it.

Exception is the abstraction and InvalidPluginExecutionException , NullReferenceException etc are the implementing concrete classes.  


I had some code where which was triggered on the change of state and depending on certain values it would be go a different route, there were lots of different routes

The abstraction was Route, I made this an interface and it was then implemented by many different Routes through the system.  If the users wanted more routes the code was made to encapsulate what varies.  

Half the code used the interface Route, any changes by adding more routes would mean the code which used the interface would need to change or be effected by the change.

Why Abstractions are so important

Abstractions help create well designed code.

The code is easy to understand because if you have captured the right abstractions is obvious what the code is doing.

Abstractions help create loosly coupled code.  The reason is the abstraction acts like a type and encapsulates the potential changes behind the abstract class/interface.  

To understand why this is import you need to understand the statement

code to an interface, not a concrete class.

A classic abstraction is creating a database layer, an abstract class or interface which parts of the code users to interact with the database. The abstract minimises the effects of change because the code which interacts with the interface will not be effected by the implementation/concrete class changing.  It also allows the code to change in the future and more types being added.

Adding more types will not effect any code which interacts only with the interface.

This brings me nicely to the design principle

Encapsulate what varies

Business rules or algorithms are a good example.  When you have a behaviour or type you have an Abstraction.  Using an abstract class will manage the effects of change and create a loosely coupled system which will manage the effect of change.

Understanding abstraction can take time

Abstractions are used everywhere because they make life easier

  • Common language
  • S.O.L.I.D principles
  • Design Patterns
  • Design Principles

It was until I began to understand the terms Encapsulate what varies and Code to an interface that I slowly (very slowly) could see how abstractions made it easier to organise code/reduce dependencies and how abstractions through abstract classes and interfaces helped manage the affects of change.

Change can ripple through poorly designed code because poorly designed code is fragile, you change one part of it and an unrelated part of the code suddenly breaks.  The reason for this sudden breaking is dependency.

Abstractions (interfaces/Abstract classes) reduces dependencies and the abstraction acts as a barrier to dependency and change.

The next stage of my personal appreciation of abstraction was when writing the blog post – How to find classes, the method of looking and finding classes through nouns and types made it easier for me to identify potential abstractions.

Studying design patterns and good code will help you to understand and learn how great code uses abstractions.  The two books below are great books to get started with design patterns, my vote goes to Head First Design Patterns because it’s easier to get started with.


Abstractions are a handy tool to understand when designing your code, it can make maintaining code much easier because you will improve readability and reduce dependencies in the code.

It’s definitely time well spent understanding abstractions in code design and it will make designing code easier.

Understanding abstractions can make you look at your existing code base from a different perspective because the potential abstractions highlight where the code might change in the future and areas of potential refractoring.


Good coding practices – Information hiding

I was reading code complete 2, which is an excellent book and I would recommend all CRM developer read it, you will learn lots of things.

The book mentions information hiding, this may be a new concept to some CRM developers because it’s not a term you hear very often.

Steve McConnell the author of Code Complete 2 has a great article on it called Missing in Action: Information Hiding

Information hiding would be a by product of code using the S.O.L.I.D principles

What is information hiding

I find it helpful to use multiple definitions, design principles it can be difficult to understand and different perspectives can be beneficial.

Programming Practices

Information hiding focuses on hiding the non-essential details of functions and code in a program so that they are inaccessible to other components of the software. A software developer applies information hiding in software design and coding to hide unnecessary details from the rest of the program. The objective of information hiding is to minimize complexities among different modules of the software. Note that complexities arise when one program or module in software is dependent on several other programs and modules.

Information Hiding

The basic idea is that if code chunk A doesn’t really need to know something about how code chunk B (which it calls) does its job, don’t make it know it. Then, when that part of B changes, you don’t have to go back and change A.


Hosk Definition of Information hiding

Information hiding is not just about hiding data but hiding how it implements those behaviours.   Classes  have public methods but hides the private methods and variables which implement the logic behind the public methods

Why is information hiding important

Information hiding reduces dependency on class variables, allowing classes/methods to act like black boxes, hiding logic from the consumers of the class.  Hiding variables reduces potential coupling and dependant classes, which will reduce the effect of change on your code.

Information hiding is not just hiding variables but the methods and internal logic.  Hiding information results in less code being dependant on concrete classes/implementation, allowing internal workings of classes without needing to change any other classes.

This blog post highlights some good points about information hiding

Why you should care about information hiding

Information hiding makes methods and variables private, hiding the internal logic from other classes.  Developers can change the internal logic without changing dependent code.

Methods should only accessed is via the public methods, hiding the internal workings of the class.  CRM developer can change the internal workings of the class and not effect any of the classes which call those methods.

If classes have public variables, public variables might be used by other classes creating a dependency, if you change a public variable you need to check the calling classes still work.

Changing the logic of public variables/methods can effect any dependent classes which will result in more code changed, more testing and an increased chance of creating a bug.

To help understand information hiding it’s helpful to think the CRM SDK.  When we call IOrganisationService.Update(Entity).  We don’t have access to any fields, we have no idea how the code updates the CRM database or what steps it does.

Microsoft could change the IOrganisationService.Update(Entity) to use a different language but because I only consume the public method none of my code would need to change (assuming it works the same way).  Code calling the CRM SDK is loosely coupled.

How you use Information hiding outside of coding

Information hiding and Encapsulation in OOP has a great definition of information hiding

Showing only those details to the outside world which are necessary for the outside world and hiding all other details from the outside world.”


Real life examples


You can hide private information from certain people to stop them using it and only show your name.

Computer operating system

Windows/Linux give you a nice GUI operating system to manage your computers but underneath there are lots of private files and programs.

The article Information hiding and Encapsulation in OOP  has a good example
  1. Your name and other personal information is stored in your brain we can’t access this information directly. For getting this information we need to ask you about it and it will be up to you how much details you would like to share with us.


Information hiding isn’t the same as encapsulation but I’m not entirely sure of the difference. Encapsulation and Information hiding share a common goal in hiding business logic.
Wiki quote

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the inter-dependencies between software components[citation needed].


The benefit of encapsulation,  hiding business logic by using private methods and interfaces/abstract classes.  Encapsulation limits the effects of change.  Encapsulation hides/removes dependency on the concrete code behind your public methods

Information Hiding helps reduce the effects of change

Code changes all the time and there are lots of things which can result in code change

  • Change in requirements
  • Fixing a bug
  • Refactoring
  • Extension

Developers cannot control change but they can control how the code will be affecting by change.  Good code design using the S.O.L.I.D principles will reduce the effect of code changes in the code.

Information hiding is one of the tools developers have to reduce the effect of change, hiding the information will create loosing coupling/low dependency and using interfaces/abstract classes will isolate your concrete implementation code from the rest of the system and create loose coupling.

This design principle is described in the Law of Demeter, which described excellent in this article  SOLID Design principles

I find it useful to refer to these principles when writing code because it helps to create

Information hiding helps reduce the complexity of code by creating loosely coupled code and more modular code.  Information hiding reduces the dependencies on classes, a class coupled with multiple classes in a system, it’s difficult to understand and change the code because you need to understand how the change would effect all the dependent classes.

Information hiding helps reduce coupling by hiding concrete logic which helps mitigate the effects of changing the concrete logic.

The more independent/loosely coupled code you have the more code reuse you will have.

Benefits of Information hiding

  • Simplifies the code
  • Reduce complexity
  • Limit dependencies in code
  • Improved code readability/Increased understanding

futher reading

High Cohesion – Loose Coupling

information hiding with Javascript

Why you should care about encapsulation

Experiences of Unit testing with Microsoft Dynamics CRM Projects

Many moons ago when I was a Java developer and learning how to code, I remember two things which had a big impact on my coding.  One was learning about Design patterns and the other was learning about Test Driven Development.

Writing unit tests for your code before you actually write the code seems like a strange thing to do and I didn’t meet many developers who did this or in fact bother writing unit test at all.

I found writing code which you knew was going to be tested with units tests forced me to write modular/reusable code.  It makes you write code which can be tested and usually this means each function does only one thing (because that’s easier to test).

The code is more likely to Single responsibility principle and each class and method doing one thing, the reason for this is because it’s easier to test something which only does one thing.

Pro and Con’s of Unit Testing

When unit tests and writing unit tests are mentioned this question is not usually far behind

What’s the benefit of writing extra code to test your code?

This can be a hard sell to some developers, it would be similar to trying to explain to a messy teenager the benefits of cleaning your room.   One the major complaints raised against writing tests is it takes extra time and we developers don’t have time to do it.

Writing unit tests involves thought and effort creating dummy data, deciding where to mock or stub to get enough data to test the code.  This can feel like a lot of wasted time when you can spend half a day getting the data created to test your code.

This effort can be too much for some developers and they will never like writing units and always view it as a waste of time.  This point of view is a common initial thought until the developer tries it and starts to see the benefits with the improved confidence of their code.

The irony of the aversion to unit testing is developers test their code by creating console apps or debugging the code. Unit testing is taking this process and making it reusable and self-contained

When writing unit test you stop and think about how the code and objects are going to be used.

Below is my experiences of unit testing and CRM, there are probably lots of companies and CRM developers are are unit testing their code

PRO’s of Unit Testing

  • confident the code works because it has been tested
  • Higher quality code (more modularised/reusable) to enable tests to be written
  • Any changes to the code can be tested quickly with no extra effort once tests have been written
  • unit tests can help developers new to a project understand how the code (should) work
  • very useful for testing refactored or bugfixed code
  • It’s easier to debug unit tests than deployed CRM code

CON’s of  Unit Testing

  • It takes extra time to write the unit tests and prepare the data
  • Unit tests have to be maintained and updated
  • You have to learn the testing framework and how to write tests (this is non-revenue generating time)
  • A feeling of not moving forward

My Experience of CRM Unit Testing

Unit tests and CRM in my experience have never really happened for a number of reasons/excuses, I have listed them below

Smaller projects

Smaller projects usually remove all non development tasks and reduce everything to the bar bones.  Unit tests were seen as non productive time the customer didn’t want to pay for.

Often small projects had a very limited about of code customizations


Developers never have enough time to do everything the customer wants and usually the first thing to get snipped out is testing and unit tests.  See Why rushed projects/code doesn’t save time and reduces quality

Best Practise/Best Testing framework

Most CRM projects I have worked on haven’t used unit testing.  below I detail some of the reasons this (I’m not saying I agree with them but stating them).  I would say I wasn’t always keen to unit test my code but part of the reason was because the code in the projects wasn’t unit tested.


Some unit test frameworks do have a cost associated with them.  Microsoft Fakes used to only be included in the Ultimate version of Visual studio (which was very expensive) but it got voted into visual studio premium on Jan 30th 2013.

CRM developers didn’t seem to know (or maybe care) about this because I didn’t meet any CRM developers who liked or did any unit testing of the plugins/custom workflows until recently when I joined my current company.

Joining a project with no unit tests

The decision to unit test usually happens at the start of the project.  Many of the projects I have worked on didn’t have unit tests.

Legacy code impossible to test

Most people don’t bother to try and write unit tests for legacy code.  I can understand this because it would be very difficult

Plugin/Custom workflows hard to test

What do I mean hard to test?  Plugins/custom workflows need a IPluginExecutionContext context so you can test the plugins.  So to properly test a plugin you would need to create a IPluginExecutionContext with the correct attributes.

This would take quite a bit of effort.  To get an idea of all the data created you can use the debugging with the plugin profiler as an example.  When you debug with plugin registration tool, you set it to record the data for a certain plugin, run through triggering it in CRM.  This will create an xml file with all the fields and values.

You can then use this file to recreate the scenario you ran through in CRM and it will pass all those field choices into your Visual studio debugger.   This blog runs through the process

No insistence of unit tests

The projects I worked on, no one insisted unit tests were created, apart from one project.   Instead the code would be tested by each developer and then put forward to an integration test.
Unit testing has to be a company or project policy or something which developers of a company are doing.

Senior developers weren’t doing it

Junior developers learn good and bad habits from senior developers.  In most of the projects I have worked on there were no unit tests.  I haven’t met any (1 or 2) CRM developers who write unit tests and most do not promote unit testing.

Examples to copy

When you type CRM and unit tests you do not get many results back and this suggests unit testing CRM code is not common practise.  More examples and blog posts would make it easier for CRM developers to use this code in their projects.

How Hosk tested his Code

The way I developed my code customizations was to create the code in separate class outside of the plugin code.  I would then create a console app and test the code by passing in a IOrganisationservice, TracingService and Entity.  This allowed me to walk through the code and retrieve data from the development CRM organisation.

I’m not entirely sure how other developers would test their code, I have a sneaky suspicion most would use integration testing (deploy and test it using CRM) and look at the log files.

This article was in draft status for quite a while and in the mean time I have started writing unit tests. I first tried using RhinoMocks and then found Microsoft fakes was free in the premium edition.

I have written the article

Why CRM Developers should unit test their code

I am now a firm believer CRM developers should be writing units for their customizations and there isn’t any excuses why unit tests are not written.  The lack of unit tests is not limited to CRM Development but wide spread in a lot of programming.

There are some difficulties in writing unit tests in CRM but it is achievable using Microsoft fakes.

CRM Project with Tests

There has been a drive to test the code in a project and the developers are writing tests for code which already exists.

I won’t lie this is a tricky a task.  When code hasn’t been written with testing in mind it can be very difficult to test.

I will say some tests are definitely better than no tests and the code was decently structured so a lot of the code plugins are using is now separately tested.

It has taken some time for developers to get to grips with the testing framework and the testing methodology.  Testing is a different mindset and it takes  bit of time to learn the tips and tricks and common testing methods.

The benefits have been

  • Tests any developer can run
  • The business logic is quite complex in the project, so having a method to step through parts of the code is very useful.
  • Tests can be run be developers who didn’t create the code, much quicker than trying to test the code yourself.
  • Easier to see if your code has broken other parts of system

Plugins and testing

Some developers can have a blinkered view of testing the plugins themselves.  Plugins are not always easy to test and sometimes a plugin doesn’t do much.

A create plugin might validate values

A plugin could update related records

I personally remove all the code from the plugin and create separate classes where the constructors take IOrganisationService and TracingService.  The method can then take an entity record which has triggered the plugin.

Unit tests can be run against the code which is split up into small focused classes/methods.

At the end you plug all the small tested parts together and link it to the plugin.

Why have I changed my mind about unit tests and CRM


Looking at the list of reasons why unit testing was done on the CRM projects I worked, I can see they are not reasons they are excuses.   Most disappointingly is some of the excuses for not writing unit code are excuses I have been making to myself.

I have been reading  Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) and Uncle Bob mentions we as developers/programmers should be testing our code and our code should be good.

He has this quote in Clean Code

Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

This year I have been thinking about the quality of CRM code/customizations and have been coming to the conclusion the quality of code in CRM projects need to be better.

I re read my post –  The Frustrations of a CRM Developer many of the frustrations come from poor code.

Quite a few of the CRM Developers articles I have written this year are focused on creating quality customizations

Before reading Clean code I knew I should be writing unit tests but took the easy option of not doing it.  After writing some unit tests for my current development, it has been so much easier refactoring my code and making changes.  Having 40 unit tests testing code change gives me confidence the refactored code works.

Unit testing helps projects from falling into a state of Legacy code because writing code you can tests makes the developer

  • Think about the code design
  • Think about what the functionality should do
  • Test the code more thoroughly
  • Creates reusable tests to all developers on the project

I hope this and future blog posts will get more CRM developers to start unit testing their code.

The biggest driver for unit testing code should come from the developer, who has pride in their work and wants to deliver high quality code.  This is an attitude, it’s a desire to create quality code.

The benefits of unit testing are undeniable and if you start unit testing your work you will soon enjoy the benefits.  If you are already writing unit tests then keep up the good work and write a blog about it to encourage other CRM developers.

Why you should write code and customizations like a boy scout

As the cost in time and effort of refactoring goes up, developers will add more bad code because it’s easier and quicker.  The result is the bad code in a project is like a snowball being rolled in snow, it just gets bigger and bigger – Hosk

I was reading an article which had the concept of the boy scout rule  boy scout rule, it’s from the pragmatic craftsman and I would recommend the excellent book  The Pragmatic Programmer

If you haven’t read it yet, I recommend you, it will help anyone who has to write any code or is doing any development.

Development and the boy scout rule

Boy scouts have a rule

Leave the campground cleaner than you found it.”

The other makes this point about code

“the code cleaner than we found it.”

What does this mean

The meaning of the quote with regards to code, is to encourage coders not to add bad code/quick fix code.

I would classify quick fix code as pushing and poking in some code to fix a problem, which adds to the complexity of the code rather than simplifies it.  It might fix the problem but if the code is poorly written and structured it is moving the code towards spaghetti code

If you think about a teenager who keeps putting off cleaning their room by hiding dirty clothes under pillows, shuffling things in cupboards.  If the teenager keeps doing this in the end the room turns into a big mess.  This is ok until the teenager wants to find something, they can’t because stuff is everywhere, there is no order and it’s hard to work out where to look.

Instead of cleaning and tidying up the room, developers when adding bug fixes, keep placing quick fix statements, which over time slowly creates bigger and bigger methods, code complexity increases.  The code because tightly coupled and starts to get more like spaghetti (e.g. code is linked together),  maintaining, enhancing and debugging the code becomes difficult.

This is where the boy scout rule should come into play

Leave the camp ground cleaner than you found it.”

If you adhere to the rule above it would mean instead of adding quick fix code, you add the code properly which may mean refactoring classes and methods and keeping the code.  It will probably take longer in the short term but it will keep the code well structured, simple and readable (why code readability is important)

Code which isn’t readable (the code which gets the quick fixes) is

  • Difficult to understand
  • Longer to debug
  • hard to maintain
  • tricky to extend

The codes growing method/class size, increased coupling and  added complexity results in the code taking more time and resources to maintain in the future.

When changing code you should focus on making it readable and adhering to good programming standards.

The benefits are

  • Removes duplicate code
  • Easy to understand
  • Consistent
  • Small methods which do one thing
  • Logically structured and designed

What I don’t like about the boy scout rule

The idea is great but when trying to explain this concept to other developers.  For developers/programmers to follow this rule it will result in them doing

  • Refactoring code
  • Writing better
  • Keeping to high standards
  • No quick bug fixes
  • Increased time and effort to change code
  • Increase in Testing

It’s the difference between quickly shoving some clothes in a draw and cleaning the whole room.  Interestingly outside of coding I am very messy person

Acting like a boy scout and follow their rules and tenants is not initially appealing to most developers, particularly if it’s going to take extra time and effort.

My point is it can be hard to persuade other developers to put this amount of effort in, even if they will benefit and save time in the long term.

How do we sell the long term benefit over a short term gain

Help your future self

What I try and do is explain to developers is this will save themselves time and effort in the future and will make their job a lot easier in the future.

If you wrote the code now, there is a good chance you will pulled back into bug fix, maintain and enhance it later on.  When you are working on a project full time, you have a great understanding of the project and you are in the project zone.

Being in the project zone means you understand the code AND all the business rules/business knowledge which goes with the project.  Like sportsman being in the zone doesn’t last and you move onto other projects (although sometimes it doesn’t seem like that).  Due to your extensive knowledge of the project, the business logic and the code you will be the prime candidate to fix any bugs which get raised.

The Messy Garden Shed

If you think of a project customizations like a garden shed.  If every time you use the lawn mower, spades, bird feed, kids toys you tidely place all the items back.  When you need to go into the garden shed a few weeks/months later you can easily find everything without having to remember where you last put things.

If you have a messy garden shed where everything is thrown into the shed and items are over and under each other.  To find the item you want you would have to try and remember what you used last (you might not have been the last user). If you can’t remember you can slowly start pulling things out, looking around.  With everything scattered around it’s difficult to know what’s in the shed, let alone where it might be.

It takes a lot longer to find things in the messy garden shed but if you went into the shed the day after you used the spade, you would have a good chance of knowing where you put it.

The messy garden needs you to remember where things are, this is similar to needing to understand the code and business logic in complex code solutions.

In six months plus time you won’t know the code and you definitely won’t remember the business rules and business logic.

So the code has to be as readable as possible and should not be complex

Scare them

You could try and scare the developers with this great quote

Why you can’t let standards drop

This is a great rule but I’m not sure how effective this would be at movitating people to tidy and refactor the code.  Unless you hired a violent psychopath to walk around the office once a month and maybe do a few code reviews.

Developers should have enough respect in their work to do this as a matter of course or to help themselves out if they have to fix the code later.


Go round the officing saying this to fellow developers at least once a day

Times may change but standards must remain

Enjoy your work and take pride in creating excellent simple code because as soon as you stop doing it, so will everyone else