To deliver a project on time, stick to out of the box (if you can)

There is never enough time to build the solution the customer thinks they want #HoskWisdom

Don’t ask a developer if a requirement needs code. Don’t ask users what enhancements they would like and don’t ask a barber if you need a haircut.

A developer told me he worked on a project that delivered on time and the customer loved it. I have worked on many projects and few delivered on time (obviously not my fault :-)), so I was curious to learn more.

On this project they kept telling the users they couldn’t have what they asked for and they were just getting out of the box. The team mantra was.

“You get whatever out of the box can do and no more”

The outcome of this stance (supported by the leadership of the customer).

  • User stories were straightforward and didn’t need lots of rewriting.
  • Development was mostly configuration with some no code customisations.
  • Testing went through with few bugs.
  • The project delivered on time and on budget.

The user got the system and loved it. After using it for a month, they came back with a few improvements and enhancements. This project was a Field Service project, but I saw a portal project delivered in 3 months from start to go live which used a similar approach.

Imagine the time saved by sticking to and trying the out of the box solution before suggesting enhancements. It seems obvious, but the common problem on projects is scope growing, expanding the complexity of the solution and testing. 

This compounds the usually optimistic estimates of a project and reduces the time you have to test and fix bugs. Problems found at the later stage of a project are deadly because there is no time to reduce scope and then go live gets pushed back.

The order of customisations

The general order of creating customisations is

  1. Out of the box.
  2. No code customisation (workflow, Power Automate)
  3. More powerful no code — (Logic app, PowerApps)
  4. Code (Plugins, Azure Function)

The reason for starting with out of the box because of the cost of maintenance. Every customisation you create has to be maintained, tested, debugged, deployed, upgraded and understood from that point of creation. Code allows you to create more complex customisations but has a higher maintenance cost and fewer resources can do that.

The benefit of using out of the box is Microsoft takes the burden of testing, upgrading and maintaining.

Charlie Munger often says that “to a man with a hammer, everything looks like a nail.”

To someone who can write code, all problems can look like a plugin, many Dynamics developers enjoy writing code more than creating no code solutions. To reduce the complexity and maintenance of your solution, stick as close to out of the box as you can.

Users and wishlists

I have seen examples of users coming up with growing list of requirements that would be nice to have and might make their jobs easier. It’s easy to capture a requirement but then it must be created, tested and moved through all the environments until you get to production, where its then supported.

Every requirement comes at a cost and the most significant is time.

The more requirements you add, the more time to deliver and the more complex the solution becomes. The more customisations which are linked the greater the complexity in understanding the solution.

Find what customisations they need, build those and let the users test the system. This delivers functionality into production and not wasting time on functionality not required. After using the system the users can highlight the pain points and areas where the new system would benefit from enhancements.

You create customisations where you need them, not where the users think they need them. For every requirement, question if it’s really needed? Show the out of the box solution and get users to test it. It’s difficult to push back on requirements but every requirement you add the more likely the project will not be on time.


  • Question every requirement, take only what’s needed.
  • Show out of the box solutions and persuade them to try them.
  • Code should the last choice.
  • Persuade users to test the solution before enhancing it.

The fewer customisations and code you create, the quicker you will get through testing and deliver to production. Get feedback from users to find out where they really need to enhance the system through them using it.

Most users don’t know what they want, until you show them what they asked for and they know it’s not that. So ask them to try out of the box and then know what they want.

Everyone on a project wants it to be successful and on time, be focused and disciplined.

Articles and quotes to make you think - 19th March

Here are the best articles and quotes I read last week, which got me thinking.


Gather together the things that change for the same reasons. Separate those things that change for different reasons Robert C Martin

“Unless people can express themselves well in ordinary English, they don’t know what they are talking about.” Russell L. Ackoff

Latest Hosk articles

10 Interesting articles last week

  1. The Powerful Differences Between Good and Great Programmers
  2. Single Responsibility Principle (SPR) explained by Uncle Bob
  3. Embracing complexity
  4. Sometimes being slightly better than the competition is enough to win big — James Clear
  5. Great advice in investing and mental models and perspectives at looking at the world
  6. How to Write Usefully — Paul Graham
  7. Using Models to Stay Calm in Charged Situations
  8. How does system thinking help solve problems
  9. How To Be Successful
  10. The story behind ‘flatten the curve,’ the defining chart of the coronavirus


  • The truth of code can be confused by the lies in comments HoskWisdom
  • Code should be self documenting, the purpose of classes, methods and variables should be obvious that you can understand it in six months time #HoskWisdom
  • People don’t care if the chicken came before the egg, but it doesn’t stop them asking #HoskWisdom
  • Stop dreaming of the quiet project because it’s the one you’ll never know — Paul Weller
  • Criticism drains motivation and confidence, encouragement boosts it #HoskWisdom
  • Design should emerge from requirements #HoskWisdom
  • A developer thinks they are the master of code, while in fact code remains the master of the developer #HoskWisdom
  • When you create two versions of the truth, the result is a maintenance overhead that drifts apart #HoskWisdom

Classic Hosk article

Questions on Microsoft Dynamics Dynamics 365 solutions and environments 

Quote a book I’m reading

The Fifth Discipline: The Art and Practice of the Learning Organization

The key to success isn’t just thinking about what we are doing but doing something about what we are thinking. Peter Senge

Code should be the one version of the truth, don’t add comments


“Code never lies; comments sometimes do.” — Ron Jeffries

Code should be self documenting, the purpose of classes, methods and variables should be obvious that you can understand it in six months time.

The reason I don’t like comments in code is because you have to maintain the code and the comments. I have seen examples where developers have changed the code but not the comment. When code and comments are out of sync, readers aren’t sure if the code or the comment is wrong. In most cases it’s possible to name the variables and methods for it to be clear what it’s doing, making comments redundant.

It’s easy to underestimate the effort needed to create obvious naming, first attempts are usually not as clear as they can be, you shouldn’t release your first draft. Make the naming clear, so someone who hasn’t worked on the code can read it and understand it.

You should add descriptions to classes and public methods because this can generate documentation. You should document code when you have written unusual code that is doing something odd that people would be tempted to refactor it.

“Don’t repeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” — Andy Hunt and Dave Thomas


Adding comments break the DRY principle because it creates two versions of the truth, When you create two versions of the truth, the result is a maintenance overhead that drifts apart.

Naming gone wrong

The naming of classes, method and variables should make its purpose obvious, removing the need for comments.

Clear naming of code relies on applying the single responsibility principle (SRP) to your code. SRP means each class, method and variables should have one responsibility. Robert C. Martin encapsulate this well by saying SRP should mean a class should one reason to change.

Reading more about SRP

Common signs you have broken SRP and the method/class is doing too much is when it’s hard to name because it’s doing more than one thing. Names like.

  • UpdateAndSave
  • ContactNumberorEmail
  • CreateReportAndUpdate

Methods which are hard to name are because the class or method are doing multiple things. This code has multiple reasons to change, hard to test and difficult to understand. Bad code is hard to name.

The truth of code can be confused by the lies in comments — HoskWisdom


Developers think adding comments helps understand the code. My experiences is comments rarely add anything to the code, or they have written comments instead of applying SRP and naming properly.

Comments are like commented out code, it adds confusion and increases the maintenance costs. Every line written has a maintenance cost and the potential to create a bug, the less code and comments the better.

Comments intuitively seem useful, but they are not what many developers think they are. The same qualities that give comments strength are it greatest source of weakness. Comments create two versions of the truth, a maintenance overhead and encourages developers to put less effort into naming. Most developers would be more productive to spend the time on refactoring the code and improving naming.

Most comments in code are written by junior developers thinking they are helping or by bad developers trying to explain their poorly written code.

Articles and quotes to make you think - 3rd March

Here are the best articles and quotes I read last week, which got me thinking


“Life is not a matter of holding good cards, but of playing a poor hand well,” Robert Louis Stevenson

Best practice is, by definition, past practice — David J. Snowden

Latest Hosk articles

10 Interesting articles last week

  1. Distilled: Clean Architecture
  2. A Leader’s Framework for Decision Making
  3. How you can turn bias against you into an advantage
  4. Why Facts Don’t Change Our Minds
  5. Clean Code: 5 Essential Takeaways
  6. Do You Make This Mistake In Conversations?
  7. The 25 most recommended programming books of all-time
  8. Problem Solving Desperately Needs Systems Thinking
  9. 8 books I couldn’t put down
  10. Business Needs Fewer Coders, More Software Developers


The reality of coding is at any point we can create bugs as easily as solutions #HoskWisdom

When writing code you need to keep in mind — Will I be able to understand this code 6 months later when I have forgotten the business logic — #HoskWisdom

Dynamics 365 error messages point you into the right direction but never give you the answer #HoskWisdom

When debugging, eliminate what isn’t causing the problem and whatever code or customization is left must be the culprit. #HoskWisdom

Classic Hosk article

The System Administrator role is a benefit and a curse to Dynamics developers

Most interesting book I’m reading

The Fifth Discipline: The Art and Practice of the Learning Organization

Systems thinking is a discipline for seeing wholes. It is a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static ‘snapshots’. Peter Senge