I can’t wait to see my program crash!
You probably have never said this to yourself or in a meeting with your colleagues. But actions can speak otherwise. There are 3 common mistakes most projects make that can spell disaster for the project and the team.
In this article I walk through these mistakes you or your team are making in developing and deploying projects, as well as provide the antidote to these mistakes.
Whether you’re going solo or on a team, read on if you find your projects fail.
Before we begin, I do give you permission to feel smug if none of these apply to you.
1. No Version Control
There are 3 major schools of thought with version control:
- “Version control? What’s that?”
- “Oh, yeah, I got that. It’s called CTRL+Z” (hint: no, no it’s not!)
- “Version control? So there are others like you? We use it in all our projects. Please, join our underground society. Our deity is a penguin.”
Since I’m writing this article you probably have a pretty good guess where I fall.
Spoiler alert: I believe you should absolutely be using version control! For any project!
What is version control? Simply put, it’s a way to save different revisions of a project. Think of it like one of those time travel movies where the good guy gets to go back in time to save the day, and each time he changes something a new timeline emerges leaving the old one in tact. Loosly, that’s what’s happening.
In this scenario you are the good guy (or girl)!
You get to save the day from failed deployment!
Solution: Implement Version Control!
By far the “industry standard” is git. There are others, including mercurial, CVS, and (oh, please, for the love of all things Linux avoid) SVN.
So, you’ve chosen a version control system. What projects do I use it on?
Check code in no matter how small the project. Who knows? Maybe your experimentation of “Hello World” in Java will evolve to be included in one of Elon Musk’s Mars missions! (say that 10 times fast)
2. Lack of Any Kind of Automated Testing
I once had a mind-numbing internship job of manual interop testing. I would have to plug and unplug different cables in different orders and record the test result (did things blow up? etc.). It was BAR, or “Boring and Repetitive.”
As an early developer, I would do that, too. I would go through the features one by one, manually. No wonder I never finished any projects. I would forge ahead, creating something specacular, just making sure (manually) all the peices worked–the login, the registration–EVERYTHING! BAR. Very BAR.
If you’re doing this, too, STOP. Stop reading this article right now and change your project setup (okay–maybe finish the article first).
Sometimes you get impatient. I get it. Creating a work of art from mathematics is exciting. As someone with ADHD, I understand the dopamine hit of seeing the pretty React page you spent all afternoon working on. It feels good to see progress.
But all that manual testing takes time. Logging in, selecting the page, entering the search form. And maybe the bug is really a back-end bug! Oh, no!
Solution: Add Automated Tests
Build from the ground up. Do not move on to building on top of your code until you’ve unit tested what you have already.
Yes, unit test may initially come across as BAR. You’re just seeing text printed to the screen saying “PASS” and “FAIL.” No music, no lights, no nothing except PASS and FAIL.
But they allow you to fail fast. Find the bugs quickly and easily and get past all the BAR work.
If you’re already stuck in (No) Test Valley, start small. Add a unit test framework for new features. When things slow down try to add unit tests to already-existing features.
I’m not going to spend more time explaining unit testing. Just do an internet search for “testing <language of choice>” and you’re off to the cases.
3. Lack of Documentation
Let’s say you’re developing a Python application and you need to toast some
bread. So you found a
However, there’s no documentation on how to toast your bread! You end up having to dig into the source code to find out how this toaster works.
Yes, silly example, but the principles are what matters. Without documentation ambiguity is the project lead.
Now think about your own project. How many new people join your team every year? How many times do you hand the project off to someone else? You can waste anywhere from hours to weeks helping someone get up to speed on a new project.
Even you–the developer–are not immune to amnesia. You may put the project to the side. I can’t tell you how many times I opened a personal project back up months later and swore another developer had written the code. But, lo and behold, the git commit messages were in my name.
Solution: Document the code.
While ideally it would be a full wiki, I realize time is limited. So at the very least do the following:
- Comments to the code
- A README containing:
- system requirements
- setup instruction
Hint: you may be able to find example READMEs to copy and paste from the Internet.
And, oh yeah, add the README to verison control.
I’ve come across some projects that don’t implement these and I’m surprised the client still has customers. So it is possible that projects survive without these practices.
However, a lot of time (and money–we all like that, right?) can be saved by implementing these 3 practices. Heck, even doing ONE of these things (like documenting) sets you ahead of 90% of the developers.
Why not give it a try?