The 80/20 rule states that 80% of the results come from 20% of the causes, and 20% of the results come from 80% of the causes. This rule is also known as the Pareto principle.
If you use this principle during material study, you can achieve 80% of the grade from 20% of the study time...
There are many examples to this rule, here are 2 that relates to development:
20% of the work takes 80% of the work time.
This means that when you have done 80% of the work, you still have 80% of the work time ahead!
20% of the code is running 80% of the runtime.
This means that a small part of the code is running most of the time, and the bigger part of the code is running seldom.
You should not assume that the project progress is linear.
Murphy's law states that is something can go wrong - it will.
Unfortunately, this law applies to development process.
For example, lets assume a development process that is made of 10 stages or tasks. The probability to fail in a single task is 5% (or the probability to succeed is 95%). This is rather small chance to fail. But what will happen, when we do all the 10 tasks?
The probability to complete all the tasks without problems is only 0.9510=60% !!!
This means that we have a probability of 40% to fail. This is a big chance to fail.
Remember that we need to do all the tasks in order to finish the development process.
If one task fails, we can't complete the development. Furthermore, usually the tasks have dependencies, so we have to do them serially.
During the development process it may be a good idea to get feedback on the plans and results of your work. You can get the feedback from the following sources:
The feedback allows you to fix problems quickly.
There are several types of bad feedback:
Don't limit yourself to your own knowledge, you can learn from other people's experience.
You can do better job with less time if you ask your boss, team mates, friends and forum posts for their opinion about design, implementation and debug problems that you encounter during development.
Do not overuse this tip, since other people's time is a limited resource.
Bottleneck is a stage in the development process, that delay the end of development.
The bottleneck may change during development.
When a single developer is working according to the waterfall development model, the current development stage is the current bottleneck - requirement, specification, design, coding, testing.
In reality the situation is more complex. You may find yourself many times waiting for another person or resource to be freed.
For example, if next month you will need to use a specific tool, that you need to purchase. It will be a good idea to order it now and not when you need it, because it may take several days to get it.
Some good bottlenecks handling habits:
Usually if you start development earlier, you will finish earlier - if you can avoid unnecessary additional features.
Starting development as soon as possible, will reveal hidden problems that might cause delays. This will allow handling the problems earlier.
You don't necessarily need to wait for the management approval order.
Starting early will reduce your schedule pressures.
Good health condition can enhance your mental skills.
You can do several things to achieve this:
Technology advance constantly forward. New development platforms and new development methods and technologies are introduced. In order to avoid reduction of your professional level, you should be updated with new technologies and lean new development methods.
New development platforms (hardware and software) can offer:
If we look back, we can remember some major developments:
How can we learn new technologies?
Red queen race: "it takes all the running you can do, to keep in in the same place" (Alice in Wonderland).
This means that if you stop learning new things, your professional level will slowly decrease.
The most common solution to project delay is to stay late and work overtime. This is a poor habit that usually overused by the management. The team leader usually thinks that if the team will work late every day, he will finish the tasks earlier and give added value to the organization by using the employees better. The team leader will also appear to upper management as a hard working guy. Actually working late hours usually give poor results, because most people can't work late without lowering their productivity. If you double your working hours it will not take you half of the time to finish the work:
Only in rare cases, it may be ok to stay overtime to solve an urgent problem.
Waterfall development model assumes sequential development process: requirement analysis, design, implementation and testing. When each stage ends the next stage begins, without turning back.
In reality this model can not be used, since many times we have to go back to previous stages.
More realistic development model is the iterative or spiral model. This model consists iteratively advancing through the development stages, while refining each stage. Each stage involves expansion stage while considering all the possibilities and focusing stage while choosing the right path.
During development you will learn new tricks and habits that will make your life easier. These skills will be your personal toolbox.
It is common practice among managers and developers, who want to accelerate the development process, to skip development stages in order to deliver the product early.
Actually this practice is self fraud, since skipping development stages can only delay product delivery. The development process has several stages:
When we choose to skip one of the development stages, we risk with late changes:
Each high level stage change will cause lower level changes. For example requirements change will cause specification, design and implementation change. This is a very big and time consuming risk, we should avoid.
During work, the developer is required to perform many development tasks.
Many times the developer is required to stop working on one task and start working on another development task. This task switch has a hidden overhead - the time that is needed to go back and resume the first task is wasted. This overhead time might be found more significant while task switch frequency grows.
This tip might contradict the free development bottlenecks tip, so an appropriate optimal balance should be found. This is the same principle of operating system tasks that should get optimal tick time, that balance between CPU efficiency and response time.
(avoid quality reduction to achieve results sooner - hard deadlines can delay the project).
A bad common habit in the development world is to reduce the quality of the work, in order to finish early. For example skipping the specification document, design document and testing. This poor habit is usually used when the project is late. The usual outcome is that the project will be more delayed! Usually there is no tradeoff between quality and finishing the project sooner. If the quality is high, the project will be finished sooner.
This is the reason why non realistic hard deadlines usually cause the project to be more late.
