Do you ever cut corners?
May 29, 2007
This is a general question, but possibly aimed at the PHP crowd more because it’s often easier to cut corners when doing development than in other languages.
“Cutting corners” can mean almost anything from skipping unit tests to skipping documentation to lax variable names to almost anything that you know isn’t optimal but you skip for one reason or another. What corners do you ever cut, and what are your reasons?
My own corners tend to be unit tests. Some projects I write them before (rare), some projects I write them after (rare as well) and some projects I don’t use them (majority). There are two primary excuses I use but they both come down to time. For example, at work, the primary project I’m maintaining is un-unit-testable (is that the proper way to write that?). The time it takes to refactor even small portions which any new code I’d write touches is often beyond the time allocated for the thwork. I did make some headway last year in refactoring some sections of the code to make some of the core libraries testable, but I was pulled off that work for another project. Basically, in that case, it boils down to the notion that the company itself doesn’t value testing as much as getting code out on o the floor in to production, nevermind the notion that future changes become that much more difficult and we end up with less confidence in the production code. It’s been a slow evolution to this point, and it’s like we’re the frog in boiling water - the water’s come to the boil only gradually.
I had this idea some time ago that the ’strongly typed’ platforms such as Java and .NET made unit-testing a breeze, but my view now is that regardless of the language, the notion of having components testable is something that needs to be designed in from the ground up. Java and .NET seem to make refactoring existing code in to testable code much easier, though (”Refactor! Pro!” was simply amazing when I saw a demo).
So, if you ever cut corners on your projects, what do you cut and why?
Did you like this post? Buy me a hot chocolate!
Posted in Design, Development, Microsoft, MySQL, PHP, Perl, Ruby, Software, Testing, Tools, Web, opensource
May 29th, 2007 at 9:39 am
To quote Jason Sweat, “detestable code - code that is not testable”
You might consider looking at functional testing rather than unit testing. Using something like SeleniumRC, you can test the outcome of the code without testing the actual code itself. That provides a safety net around the deployed project that allows you to refactor the code later while insuring that you’re not breaking the intended functionality.
May 29th, 2007 at 3:48 pm
My answer is simple, I cut features. I have to have tested and documented code, especially in a team driven environment. If lack of time is your problem, then the person that assigns the task in a specific amount of time needs to do their job better and track their history and learn from their mistakes. Software engineering is not suppose to be a rushed profession although people want to treat it as such.