The Definition of Completed

By nature, software developers set out to please their management by completing their tasks as fast as possible. This is admirable and ultimately what management desires. However, software developers interpretation of "complete" falls short of what their management expects.

Over the years, it has been observed that junior engineers tend to dramatically under test and prematurely rush projects into the completed state. It is also possible to over test, though generally this is the minority. There exists an ideal balance of testing where all of the valid edge cases have been tested via automated unit and/or integration testing.

Ultimately, management considers the time to completion starting from initial development until the task is reliable running in production. This includes any fixes required, time to test those fixes and finally get them into production. In an ideal scenario, the software developer identifies all of the defects in their initial testing and the code can then be deployed successfully to production without delay. When code requires multiple code reviews and is kicked back multiple times for quick fixes, the total time of this delay including idle and context switching time (the time lost to switching to different tasks) is included in management's perceived time. Even if the fixes are rather small and quick, the total delay is what is measured.

Numerous studies have determined that the further along in the process defects are found the more they cost in time and money to fix. This means that leadership in any organization always desires to identify and fix defects early, preferably duringwith the initial development phase.

Some hints for developers to help improve their end results:

• Start measuring your development time on tasks the same way management does. How long does it take to get into production, not just your time working on the task. Constantly re-evaluate your role to ask how you can reduce this time (don’t fall victim thinking this is outside of your control).
  

• Improve your testing. Constantly re-evaluate why your prior tasks were kicked back and improve your testing in those areas. One hint is to "sleep" on your code. When completed, wait overnight and look at it again the following day to see what you might have missed by performing a self code review and re-test. It is amazing how different your code looks just one day later. If you do not have that much time, then take a short break from your work and come back to your code then.
  

• Ultimately, avoid making the same mistakes multiple times. Humans learn through making mistakes, take the time to do personal retrospectives on what you can improve upon.
  

• Pay attention to the details. If something does not make sense, speak up and ask questions for further clarification instead of assuming.
  

• When you finish your assignment, if you do not like your solution, then do not turn it in as your work; fix it. Don't take your management's request as literal. Often times they are rushed and trying to give you guidelines not exact requirements.
  

• Listen to the advice of your team and peers. Their feedback and criticism will be the most rewarding and helpful as they work much closer to you than your management. Be open and honest with them.