The idea for this post came when I was driving and listening to the Zen and art of Motorcycle maintenance.
The book is full of interesting questions and will make you look at the world and has some fantastic concepts
It unsurprisingly talks quite a bit about Motorcyle maintenance, which I thought would be boring (I’m not a fan of maintenance with my soft developer hands). One part of the book focuses on how a mechanic fixes a motorcycle, he doesn’t see the bike as a physical set of tires, metal, etc, he sees it as a whole set of logical systems all linked together. So when the mechanic is fixing a the physical chain, he is fixing the theoretical mechanism which is used to move the wheels.
Quality
A recurring theme in the book Zen and the art of Motorcycle maintenance is Quality, it devotes many pages to it.
Here are a couple of good quotes from the book
“The place to improve the world is first in one’s own heart and head and hands, and then work outward from there.”
― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
Quality tends to fan out like waves.
ROBERT M. PIRSIG, Zen and the Art of Motorcycle Maintenan
You can read about Quality as mentioned in the book by clicking the links below
Pirsig’s metaphysics of Quality
Whilst listening about quality, I got the idea for this blog post and I pulled over on the hard shoulder and started scribbling in my one of my many super hero notebooks (this one was amazing spiderman)
Alternative titles and quality
The title of this blog post could have been any of these and it will give you an idea of what the blog post is about.
Rushed projects lead to technical debt
Rushed code = Poor Quality code
Quick projects cost you time later
Why quality is important
more speed less quality
The blog post started on the topic of rushed code and rushed projects create the same amount of code but the rushing part reduced the quality of the code and customizations.
It became clear to me whilst writing, it wasn’t due to the speed of the code but the quality of the code was reduced due to the development processes which were omitted.
Rushed Code and Customizations
I’m 99.9% sure all CRM developers and any other developers have had to create some rushed code at some point. Let’s define what I mean when I refer to rushed Code/customizations and projects
Rushed code/customizations/projects involve knowingly missing out steps to deliver the project in a shorter time-scale.
rushed code (usually implemented in rushed project) will miss out steps to deliver code quicker
The assumption made by a lot of project manager/customers is they can remove parts of the development process without reducing the quality of the end product.
The key question is what parts of the development process are removed, to answer this we need to understand the steps in CRM development
- Gather requirements
- Design architecture
- Design code
- Write code
- Test code via unit tests
- Peer review
- System Test (GUI)
The goal of the process is deliver the functionality, creating a solution which is as simple as possible with the fewest bugs
Why simple as possible?
I have written about why code complexity is a problem before in the blog post The problems with complex code and complex CRM Customizations
The benefits of Simple code and customizations are
Simple to read and understand
Simple to maintain
Simple to extend
Simple to debug
Simple to test
If you replace the word simple with the word quicker or easier, this explains why simpler code and customizations are so beneficial
The opposite of simple (in my mind) is complex code, below are some of the problems caused by complex code
- difficult to read and understand the code
- hard to test
- difficult to debug
- tricky to maintain and extend
- hard and sometimes impossible to test
- So what steps get removed
The steps most commonly removed from the development process are usually the parts of the process which don’t involve creating customization and code.
- Code Design
- Unit Test
- Testing
- Refactoring
- Peer review
As you can see all the non-code parts are removed because the project manager/customers cannot or have chosen to ignore the difference between good code/customizations and bad code/customizations but are merely judging the end product by number of lines of code/number of customizations.
Why are non-code processes removed?
Customers/Manager believe developers are only really working when they are writing code or creating customizations, I’m not quite sure where this idea came from but here are my best guesses
- When developers first start developing (particularly if self-taught) they start learning by creating code. Inexperienced developers believe developing is writing code and do not yet understand the value of the non-code related parts of development.
- Code/customization is the end product, so the shortest amount of time creating this must be the most efficient uses of the developer
- Some developers do not enjoy or see justification for the non-code writing parts of development and don’t do them
It’s a question of quality?
This strikes me as similar to someone building a house but instead of planning and designing the house they just get straight out and start putting down bricks. The end product would be a house but is more likely to be a house which could be huffed and puffed down by a big bad wolf.
When/why is rushed code and customizations
rushed code/customizations are created when things have to be done quick, the kind of estimates which leave enough time to create the code/customizations with no provision for design or things going wrong
Here are the common causes of rushed code/customizations and projects or reasons for missing out development stages
- Emergency Fix
- tight/impossible project deadline
- Change request
- Quick/Dirty fix
- Poor development processes
- inexperienced developers
- Lazy/poor developers
I originally attributed the removal of development stages to projects/customizations being rushed but it occurred to me the non code development steps are also willing removed by some developers. These developers are usually either inexperienced or poor/lazy developers.
A developer who believes he can write code with little design and no peer review or unit tests will create poor quality code more often than they create good quality code – Hosk
What motivate rushed code/removal of development steps
I will refer to the removal of development steps as rushed code, even though this happens sometimes by choice and not under time constraints, the end result in my eyes is rushed code.
There are two key types of people who create rushed code
Customers
Lazy developers
Customers will often push for short time-scales, going against the estimate and advice of developers.
Lazy/poor developers will rush the code because they do not want to either spend time doing a proper code design or often don’t like writing test units or other developers peer reviewing their code.
You can understand the initial logic of customers believing projects delivered in a shorter time scale must be better value. The customer and the project manager can pat themselves on their backs at getting more for less.
It’s my belief they should be kicking themselves up the backsides because by rushing projects you generating poorer quality projects, which will be a lot more difficult to maintain and debug and likely to contain more bugs.
It is a known practise for some companies to lower bids for projects but the only way they can deliver projects at lower costs is by spending less time creating the code. Less time spent creating code means the removal of non coding development process. The consequence of removing the non coding but quality increasing development steps is a reduction of quality in the end product.
Reduced price = reduced quality
A lot of the time the cheaper version of a product is cheaper because the quality is reduced. If you compare the Apple Ipod to the many cheap MP3 players (which look remarkably like the iPod) there is a difference in quality. The cheap MP3 players are
- Feel cheaper
- break more easily
- hard to use
In this example you pay less and you get an inferior product, the quality of the product is reduced along with the price.
Rushed code I feel falls into the second category of reduced quality. The main side effect of reduced quality is increased complexity and a lot of technical debt.
Why do customers ignore quality
When customers push for shorter delivery dates they are agreeing to creating a finished product of reduced quality.
This seems odd behaviour which the same customer wouldn’t do outside of work. If this customer was getting a house built or hiring a plumber to install a boiler or hire a mechanic to fix their care. Would the customer
- Would the customer hire someone who was really cheap but not very good?
- Would the customer get the job rushed and agree to corners being cut?
- would the customer allow the house to be built with minimal design and not testing of the house?
The question is why is this behaviour seen as ok with CRM projects, particularly when some CRM projects are big investments for companies.
I believe customers are judging the successful delivery of a project using the wrong criteria. Projects should not be deemed successful if a version of the CRM project goes live by a certain date.
Successful projects should be judged by
- What functionality was delivered by the project
- How many bugs were found in the project
- Did the project release go without problems
For a CRM project launch to be successful it’s vital the project is released with as few bugs as possible and with key functionality included. Early setbacks in a project or a disastrous initial release can stop the CRM software from being used by the end users because they can easily lose faith in new software if it’s full of bugs and doesn’t work very well.
A successful release of a CRM project will give the users confidence in the system.
If you get it wrong on the initial release of the CRM project, sometimes you won’t get another chance to win the users over.
Why Quality is important
Apple are a great example of quality products. Most of the apple products (iPhone, iPod, iPad) are quality products which are easy and fun to use. This quality allows Apple to sell their products for a high price because the user knows they are buying a quality product and they consumers are willing to pay more.
Quality in code is an interesting concept because CRM Developers can look at some code and in most cases will instantly know if it’s good or bad code but if you ask a CRM developer what are the characteristics of good code, they will stop and think and won’t be able to give you an instant answer.
The design phase of a project and design of code are probably the most important phase of a project and creating code.
The design and structure of code, will sort and organise the code in small simple parts. This greatly reduces complexity of the code.
The simpler we can make the code the easier it will be to understand the code in six months time when our business knowledge of the code and the system has diminished. When developer a CRM project, during the development the CRM developer will have very high levels of business knowledge. The CRM developer will understand the code in detail will understand the business requirements and rules of the customer.
When the development phase is finished and the CRM developer works on other projects but later works on the original project, the business knowledge and code knowledge of the system will have reduced. If the code is simple, the CRM developer will easily be able to understand the logic of the code and enhance and debug the code.
If the CRM solution is complex the CRM developer needs the high level of business knowledge to understand the code, this is where rushed projects really suffer.
Rushed projects suffer from technical debt because the development processes which get removed
- Testing
- Refactoring
- design
- peer reviews
- documentation
The processes which get removed to save time (or the CRM developer can be bothered to invest the time) are all focused on the quality of the code. The tasks focus on ensuring bugs don’t exist, the code is as simple as possible and can be tested. All the processes reduce the number of bugs in the CRM solution and are designed to keep the code well structured and lean.
What does rushed code look like
Rushed code like its distant cousin bad code has a smell. Code starts to smell when it isn’t right, learn more about code smells by reading the wiki article.
When creating code it’s a constant battle to keep the quality high and the code simple, as soon as the standards start to drop the complexity of the code will start to rise and any interaction with complex code takes longer.
You must control code complexity. Uncontrolled complexity will drag the code down until no one wants to touch it.
Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing and this will increase the complexity of the code.
Rushed code = greater code complexity
Here are some of the main culprits of complex code taken from here
- Large methods – Monster methods
- confusingly named classes, methods and variables
- methods which do lots of things
- not consistent
- tight coupling
- dependent code
- poorly structured code
The other sign of rushed code is no unit tests and a lack of documentation.
Consequences of rushed code
Quality manufactured goods last a long time and are usually a pleasure to use, the same is true for quality code. Quality code is great to use for CRM Developers when they are reading/understand, debugging, maintaining and extending.
CRM Projects are expensive investments for companies so it surprises me they want to reduce the quality of the solution created because this I believe should the goal of the CRM development. Create a high-quality CRM solution which delivers the required functionality and do it right first time.
I believe customers, managers and other people pushing for rushed code should be asked
What is the goal of the CRM project, is it to create a CRM solution quickly or is it to create a quality CRM solution. Is it time or quality? The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high. If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.
The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high. If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.
Borrowed Time
Producing rushed code is like taking a short-term loan out, if you don’t pay it back soon then the interest will keep building up.
The currency used with projects and code is time. Rushing the code will save you a bit of time now but the long-term effects of the rushed code will cost you more time later
Rushed code is like paying for a car using your credit card and then paying back the bill slowly each month. If you want to buy a car you should get a proper long-term loan out.
CRM projects do not seem like the place to want to cut corners and reduce the quality of the end CRM solution by rushing the project to shorten delivery times. Particularly if the company plans to use the CRM solution for many years to come.
One of the key consequences of creating rushed code and rushed CRM Projects, is any further enhancements or code interaction will take more time and resources.
Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing
The code will contain more bugs
The CRM Solution/Code will not be optimized and could run slower
The CRM solution will have increased complexity
You will have no tests to run against the code base, increased chance of missing bugs. Unit tests are a valid way for new developers on the project to understand and step through code
Business logic
It’s important to create documentation and tests when you creating the project because you knowledge of the business logic (e.g. customer logic and code logic) will diminish the longer you spend away from the project.
No documentation and unit tests mean you have to relearn everything and this will be more difficult if the code has been rushed because it means the code will be more complex.
More Bugs
Rushed code will likely to include more bugs. The reason for this is because no unit tests have been written (which can find bugs), no peer reviews of the code.
Bugs found later in a project will cost more time and effort to fix. You can read the two discussion to find out more
Is it significantly costlier to fix a bug at the end of the project?
Software Defects – Do Late Bugs Really Cost More?
Without having statistical evidence it would seem to me bugs found later would take longer. If you take into account the process of the customer raising and logging the bug, time to understand and then recreate the bug. Bug hunting will probably be harder if the person hasn’t used that part of the system or knowledgeable of the code (e.g. not in the project zone). Moving the code through all the CRM environments. It seems logical that it’s harder to find bugs later on and then the fixing and promoting the bug fix into live will take longer the later you find the bug in the development process.
Technical Debt
Rushed code will have technical debt due to the short cuts taken to produce the code and customizations faster.
If you don’t know what technical debt is read this wiki article and it’s basically refactoring and changes which you owe the code/project. Technical debt are code restructuring changes you have put on the list called TO DO Tomorrow.
Just like items you put on the TO DO tomorrow list, they don’t always get done, which means the technical debt keeps growing, which consequently makes tackling it a bigger and bigger problem.
Poor readability
When developers look at code they scan it to get an understanding of how it works. Before you can debug or extend code you have to understand what it’s doing and how it works, this makes readability very important
If you struggle to read the code, how the hell are you meant to fix it – Hosk
Rushed code can be inconsistent and complex because it was created quickly.
Summary
Rushed code or not creating the code and customizations using all the development steps will create complex code of reduced quality.
Working on rushed projects is not enjoyable, good CRM developers do not like creating rushed code and customizations of reduced quality. It feels wrong at the time and hard to use later on.
When you create rushed code and customizations any time saved on the creation of the code will be lost when the code is worked on later.
When you create rushed code you are agreeing to create a CRM project of lower quality
Hosk's Dynamic Blog 
24 thoughts on “Why rushed projects/code doesn’t save time and reduces quality”