Even Valve struggle sometimes (sorry Gabe! Love Steam!)– by Matt Bates
The easiest thing in software engineering is starting a project. You open your favourite IDE or text editor, stare into the blank canvas then throw yourself into the gaping maw of possibility yelling “this code will be the most beautiful code anyone has ever written” on the way down.
The hardest thing in software engineering is finishing a project. You open your IDE or text editor (which now takes too long to open) and stare into the abyss of compromise and despair of the code that you and your team has written. You say to yourself “Why is this like this? I don’t remember doing this? Whatever, I just need to fix this issue today”.
Then of course you still have all the tests and internal docs and external docs and deploy scripts to do. Maybe you don’t have to do these things, they won’t help you get this one issue fixed. Maybe you should just start again, you know all the things that went wrong on this project, you won’t repeat those again. So, you open your favourite IDE or text editor…
Keeping up momentum on a project until it’s done is hard, really hard. It’s hard when it’s just you that you need to motivate, it’s really hard when you have a team of developers.
A few things that we have found to help include:
- Make sure everyone on the team knows what “done” means
- Try and keep the projects / releases small to avoid the feeling of a death march
- Keep the communication working so problems / changes are highlighted as early as possible
Finishing things is as much a skill as development is. Anyone can start something and write code, but being able to finish something, get it deployed and have people use it is what sets engineers and non-engineers apart.
On a personal level I think the 2 most important skills for a developer to learn are: How to debug
things and tenacity. If you know how to debug a problem and you don’t stop until you get to the root of the problem or to a solution then you can solve just about any problem. I also think that these are learnable skills that come with experience, I would know, I was terrible at debugging when I first got started.
Disclaimer: I have forgotten much about WPF
I remember working on a WPF application circa 2009 and for some inexplicable reason it would run very slowly for a handful or users. After weeks of trying basically everything, including the “usual” fix enabling / disabling Windows Narrator (due to how it interacts with the WPF automation tree), we couldn’t fix it. Luckily, for these users, my boss at the time didn’t give up. Turns out the problem was an older NVIDIA driver for the Quadro FX line of graphics cards, update the driver and the problem went away.
If you find yourself staring into a problem where the only solution is “I need to throw this away and start again”, you should do 2 things:
- Remember that the person before you (which may have been you) has done this already
- Ask someone else on the team if this is a good idea (it might be!). They may not know or disagree, the important thing is that you have said it aloud, which as we all know solves all problems
If your team is relentless in their pursuit of getting to the bottom of a problem, you will probably find that you will have an easier time in keeping up momentum on a project. If someone is struggling and that is communicated to the team, then the team will combine into a solution Megazord.
Developers, you must act swiftly, the codebase is in grave danger!