10 typical problems in software development projects part I

Today’s post may not be anything you don’t know yet. Software engineering is a craft and takes time to perfect, but a lot of typical problems can be addressed. Always when I google “problems in software development” I end up on this page on tech republic, stating 10 common software development problems. In this post I will address the first 5.

  1. The “Pregnant woman” mistake
    The gist of the paragraph is that 1 woman can have a baby in 9 months, but 9 women cannot have a baby in 1 month. In other words, throwing extra resources at the problem does not necessarily improve productivity. I can’t argue with this, but there are some things that can be done to speed up the process with extra resources, and slow down less when key people are missing.
    • Establish a proper routine. Routine works in a development process like a conveyor belt does in a factory. Add more people and the belt can move faster – but don’t expect 100% more output when you double the resources. When a routine is running for a while, you don’t slow down further than usual when key people are absent.
    • Establish the right patterns in your code and stick to it. Solve similar problems with similar solutions. This makes sure that everyone involved knows how to maintain or extend other people’s code. Also, when you teach new people these patterns, and they should be productive a lot faster.
    • Make sure your developers work full stack. Ensure that knowledge about the system is prevalent among all developers top to bottom. More eyes on the problem will find issues faster. Solving it can generally be done by only one, though.
  2. The wrong metrics
    Managers look at the wrong metrics to determine success. Our advice – establish the proper definition of “done”. Although this definition varies between projects, they have in command that it means unit tested, acceptance tested, checked-in to the staging branch, and running on a staging server.
  3. Estimating times too far out
    Don’t make promises you can’t keep. With an initial project description you can have a good idea of the complexity and size of the project, but you cannot schedule what every developer is working on in 2 months from now. Users request for new functionality, and priority shifts as soon as the first bug is found.
    • Educate your client or boss. Engineering is not a task like sitting behind a cash register. You can’t measure output as easily. Sometimes the best output you can have is removing code.
    • Adjust the planning every development cycle. Keeping track of your velocity is will help you make your planning more realistic.
    • Making the process as transparent as possible. Show stakeholders what you are working on. Register every bug and new feature request. Even if they are small. This will help your client see how much time things really take.
  4. Estimating times too broadly
    I have just written a post on how to estimate your software development effort better. Make sure that your estimates are based on data, comparable features and assess the number of function points.
  5. Failing to account for tasks
    Probably the number one cause of failing to meet deadlines. The original article talks about forgetting to schedule for a critical task like testing however I also see too often that that teams only account for situations in an ideal world situation. Users make mistakes, and they need to be able to recover from that – this can be the key to having a successful application. Work from your UI backwards to see what the actual work is that needs to be done. When you create a new user for your system, you probably need to send him/her an email. HTML email is the standard these days, so the email needs to be tested in all popular email clients. In more secure systems, the email will contain a link to activate the account. If the account is never activated – is there a background process that deletes the user, or invites him again? All work that is easy to miss but is going to take you more of your times than just saving a new user record in the database.

Part two of this post will follow soon! Please comment if you have any questions, and share if you learned something new today!