As you can guess from the title, I am frustrated. I am frustrated by the fact that we neglect the solutions to the problems that already have been solved. It’s painful to admit, but I am also infected with this particular disease. More often than not I tend to overlook some of the things in the project that might have saved me from a lot of trouble a couple of times and might have saved me from long debugging sessions and painful setups. Now, the goal of this blog post is to share some of the solutions to problems that we tend to overlook while developing our software.
Let’s talk about the boundaries
Now, imagine a service or an API that works two hours a day or only when there is a certain temperature in the room. There is an immediate solution to this problem: to switch providers. Unfortunately, this is not always possible. If that is not possible, you will need to isolate it. If it is some kind of data source, try to clone the data to your service and work that way. Good design of the application separates all the parts of the system and if the architect of this application has done his job well, then it is really easy to modify this thin integration layer when a third party provider decides to change the format, structure or query language of his service. When you write code, think about the isolation. There are tons of patterns and ways to deal with external component isolation, just do your own research. Don’t base your business on the expectation that “the guys on the other end of the wire will get better”.
Ain’t nobody got time for tests
Now, I feel that this is still a controversial topic. The problem with “No tests” approach is the fact that you are afraid to change your code and it decays quickly! Even if you have a dedicated QA team, that will go through the application and test everything manually, you still won’t be able to change your code with a feeling of peace in mind. Personally, I don’t like bug reports that state the fact that Y broke because you’d changed X. Do I want to ask a question “How can you refactor your code without being afraid all the time?”? Yeah, you can write bad tests and they can run slowly, but how will you learn to do that if you don’t even try?
There is, of course, a debate on TDD vs “Test after” approach, but I would rather have this discussion than a discussion on whether we should write any tests at all.
Shared development database?
I remember when there was a time when developers sent each other snippets of SQL and executed those snippets on the local machines. Or there are still some teams that are using a shared development database for their project. Guys, the time of a shared database and SQL snippets is over. There is a tool that helps to solve this, no matter which language you use. The tool is called MIGRATIONS. Stop breaking each others development machines and code, and start saving all your database building in source control.
Invest in tooling
Does your project take 1 day to set it up? It is not normal. No matter what you say – It is NOT normal. Full stop. You must be able to set up your development machine in 15 minutes and this time period should be dependant on the speed of the CPU you have. As a good craftsman, you must keep your tools sharp. The deployment should be fully scripted, set up should run smoothly and CI should always have to scream at you when the shit hits the fan.
Conclusions
Let’s keep sanity in software development. Let’s improve our lives and stop wasting our and client’s money for stuff that is useless.
Love your craft!