We often find blog posts about the hot new thing, or how adopting an old paradigm changed everything.  What we seldom hear is stories about lessons learned from bad decisions.  I’m often encouraged by developers sharing hardships I can relate to, so I’m not going to shy away from this subject.

Testing, or lack there of, is something I’ve historically not done well.  When I began the app I’ve worked on the longest, Test Driven Development (TDD) was a fairly young idea. I was aware of it, but did not understand why you would write twice as much code as you need, while your boss breaths down your neck.  17 years later, I can confirm that I should have written tests.

Every day, I am challenged to make changes in this system, and make them safely.  Before I can begin to fix almost any issue, I take the time to write a test to prove show the issue I’m correcting.  In addition to not having existing tests, a system not designed to be tested often requires a substantial amount of setup to begin testing.  Signing in, navigating to a given page, and then finally performing some action.  Only once all of these actions are in place work may begin.

Not only does testing effect your confidence, but it can also effect the design and architecture of the system.  The Perl application which I work on is essentially a templating system with code embedded in individual pages, rendered by a web server.  When testing, this often means that any test must be run as a web request, increasing testing time and complexity.  Refactoring code from this system into Plain Old Perl Objects is one long term solution for this issue.  This refactoring is a major trigger of overwhelm in my day-to-day, I have to admit.

I breezed right over something important up there when I referenced my boss breathing down my neck.  One of the hardest obstacles to overcome for me has been changing the culture of the company I work for.  It seems common that small businesses in the late 90’s and earth 2000’s, were lead by ambitious sales folks who would impart their sales-focussed drive upon their technical employees.

While this is not always a negative, it is very difficult to overcome the, “results now, we’ll deal with technical debt later!”, mindset.  At the time this can seem like a good idea, but in my experience, the “later” for dealing with technical debt never materializes.  There is always a new feature which will allow sales to land the next big account.

If you’re working on non-trivial software, write tests.  It will save you anxiety later, help you build better software, and help the company in the long run.  I cannot advise you to falsify your estimates to your superiors, but sometimes it is important to protect the company from itself.