Rob Raux: Running, Programming, Parenting, Living…

4 things I dislike about my programming

Here’s a list I have compiled of things that I dislike about programming. Some of these things have happened in the past, some happen currently to me.  I feel like I am in control of these, so the fault is simply my own.  It can be difficult to break out of the status quo once the ball gets rolling.

1. Regression testing through unit tests. It is so easy to skip writing unit tests.  If they don’t exist, someone needs to keep testing functionality that has been tested in the past.
   
   This is an expensive endeavor and seemingly violates the whole purpose of using a computer.  A computer should be utilized to complete repetitive tasks. To me, there’s nothing more repetitive than testing every case you can think of over and over again.
   
   Other issues occur when things break you wouldn’t expect to break. Who knew that changing A would break something in B?  We didn’t, so we didn’t think to test it.  It’s not wonderful to find that out after the code is already live and it reflects poorly on you as a company.This type of things is even more pronounced in a smaller environment where  time is tight, testing is tough, and a few screw ups are expected.
   
   If unit tests get built as the application is created, you always have a full test suite which guarantees base functionality is not interrupted for your users.  More importantly, you have guaranteed peace of mind.
   

   The biggest resistance to dedicating this amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The harder the test is to write the more you need it because the greater your savings will be. Automated unit tests offer a pay back far greater than the cost of creation. [source]

2. Presentation is mixed with logic. Even having separate views, there is still way too much logic in display templates.  It seems that logic is inherently part of a view.  It would be fantastic if one could simply have a designer perform all of the HTML/templating, and leave the supply of the data sources up to the programmer.
   
   Most great programmers don’t make great designers, hey, they’re programmers.  And most designers don’t make decent programmers.  I’m sure the exceptions exist, however I certainly haven’t seen them.  If we are able to separate something along those two lines, imagine how much better an application could look, while still allowing for updates post design.
   
   There is the MVC, which is probably the best main stream architecture pattern there is, but I want more.
3. Databases changes are a pain to track. Making changes to the database are hard to track and easy to lose. When did we add that field?  Is it on production — we have to look.  What if we need to rollback? Yuck.
   
   The best solution I’ve seen is the Ruby on Rails migrations. You can rollback, be database agnostic, keep changing in revision control, etc.
4. Requirements are not clear. Requirements should be semi-transparent before beginning work. Often times the programmer thinks that the person writing the requirements has thought through every case and has covered all of the important points.  They are often very wrong.  Not only is it difficult for the writer of the requirements to make things clear, they often are not aware of the underlying software architecture (or at least sub-architecture) that they are requesting be altered. 
   
   That means the solution to this problem lies with the programmer.  Questioning, planning, and reviewing before beginning the task can save significant grief in the long term.