How do you tell when you are finished working on a change you are making to the code on your current project?

Do you decide you are finished because you are bored and tired?

Or are you done because the work is tedious, and every change is time consuming to test?

Is it done because you are impatient to get on to the next task and you just can’t be bothered to invest more time in this one?

These are terrible reasons to declare that a change is done – and yet they are reasons that I have been given by many early career software developers while chatting at conferences and code camps.

I have been around in the industry long enough that I have had to pick up the pieces after code like this is shipped and it is never clean, or easy, or tidy, or welcome.

Some fictional examples, partially based on real world situations I have experienced, on stories I have been told, and with the details changed to protect the guilty.

Remember that Excel import process from a couple of years ago that was supposed to look for a tab named with the customer’s Id, but where you hard coded it to use the first tab instead and never went back to fix it? We have just discovered that our analytics for all twelve largest of our largest customers are all corrupt – and identical – because we have been importing the wrong information.

Remember that Github build workflow that runs for every PR to test whether our project works properly across multiple platforms? It has only ever been running the builds on Linux, so we have been releasing untested Macintosh and Windows builds. We now suspect this explains why over 40% of our paying users are on Linux – most of the people who tried out our product on other platforms had a lousy experience, and we’ve lost millions.

Or do you remember your square tiling algorithm where you assumed the GCD of screen width and height would result in at most a few dozen tiles? That did not work so well on low resolution laptops with 1366x768 screens and killed performance completely.

You are not done just because you are bored.

You are not done just because it is tedious.

You are not done just because it works for a few happy path cases.

You are done when the code is complete, and you have verified that it works. All of it.


blog comments powered by Disqus
Next Post
Keep your promises  14 May 2022
Prior Post
Fixing GitHub Authentication  28 Nov 2021
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
April 2022