TwitterDid Your Boss Thank You for Coding Yourself To Death? reflects on the ever important point of overwork that seems to happen quite often in the software industry. To me experience has shown that the following points mess around with delivering software on time and increase the work load on software developers. And unfortunately, it keeps happening with projects till it feels like deja vu.
Unrealistic Estimation
One day you get an email saying, “Oh, we need features X, Y and Z in the product. We are sure you can deliver these by the end of the month as the client is expecting them. Thanks.” While I may be exaggerating a bit, the point is that estimating and promising work you do not know about is ridiculous. Software estimation is tough as it is and the only people who can get as close as possible are the developers who will work on it. Unrealistic estimation just increases the pressure on developers and they end up overworked.
For any software project to be delivered on time, estimates have to be made by developers and estimation does require some thought(Evidence Based Scheduling).
Communication gaps
Communication between the business team and the client ought to get the requirements clear. This is not possible often because many a times the client themselves do not know clearly what they need. At other times, there is a communcation gap between the two and what is understood is not necessarily what was meant. What this means is that requirements have a possibility of change. Such communication gaps will increase the backlog on developers and they end up overworked.
To avoid this the developers can try to make sure the requirements are clarified as the project progresses. This may mean change to the already developed software but change now is better than when the product is complete. Smart developers also manage a design which is flexible enough to withstand change easily.
If you are in an offshore outsourcing model, communication between the offshore-onsite team is also important to avoid schedule slips. Resolving queries should happen as fast as possible. Different time zones can also play a role in such situations.
Rigid Development
Once developers get the requirements, they start working on creating the features in the product. “Ah”, say the developers, “We have plenty of time. Let us be cautious and make sure we get all the requirements done.” While this actually sounds quite good, the only problem is that the requirements are not stable. So you shot something but it was not the deer they wanted and you have to start over again when the requirements change (and they will in most cases). Well, back to the drawing board and it’s overwork time for you and your team because of such rigid development.
A good way to avoid this situation is to deliver as fast as possible using something like the Tracer Bullet Technique. This helps the client to test out something, clarify if it meets their requirements and provide their feedback. However care has to be taken to mention to the client that this is just an incomplete version and may contain bugs. But how do you develop the project in such a short time? You can’t. But you can perhaps deliver a few features at a time. Good developers can make this possible and ensure that they do not get overworked at the later stages of the project.
Improper Testing
The first version of your software is out so testers start testing. But there is just one tester and the poor guy is getting overworked. Oops, he just missed some cases. Everything is fine and the product is delivered to the client. One day, the client’s scouts honour, always working website just goes down. Developers are called in to find the issue on the production system which is time consuming and they are overworked. Ah, they found it but it’s an issue that could have been found in system testing.
Good testing is as important, if not more, than software development. If the testing is improper, it delays the detection of bugs and increases the pressure of fixing them later in the project. Major bugs should be reported and fixed immediately perhaps even at the cost of restricting further development till those are fixed. Like good developers, good testers are needed to recognize that detecting the major issues at the start is a good thing for the entire team because it then reduces the chances of overwork which happens during the later stages of the project especially due to bug fixing.
Related Posts:
Tags: development
Frank Silbermann (2)
Abhishek (1)
Asim (1)
Igor Popov (1)
ManiKanta (1)