Skip to main content

Posts

Showing posts from October, 2014

Do it right - violate YAGNI

You Ain't Gonna Need It or YAGNI is about not writing code that is not needed. I've gone on to realise how important this is when it comes to programming for change.One of my biggest pet peeves that I have experienced working on agile teams is the excuse of YAGNI.YAGNI is no excuse for doing a "proper job". The third step of the TDD cycle allows you to take the simplest thing that could possible work and refactor it into something more dynamic, flexible or just plain better.If you spend your time writing the simplest thing possible such as brain dead procedural statements one after the next, the whole benefit of using TDD or writing automated tests is gone. You'd be more than capable of doing this yourself.My discover here was simple. Don't skip the refactor part of TDD. Don't allow someone to play the YAGNI card. Do it right.

Characterization Tests

Having worked with some truly awful codebases a common problem tends to arise every now and then. You need to make a change within some legacy component that most likely has limited or no automated tests around. This can be a scary process. There are a few techniques you can use to limit the fear of breaking some legacy code such as sprout methods or classes, however these aren't always optimal in all scenarios. Another option is characterization tests or "what is this bit of code actually doing?".Start with a simple test such as "ItWorks".Run the test - watch it fail.Using the stacktrace or error reported, write some additional setup.Run the test - watch it get past the previous error.Rinse and repeat step 3 - 4 until green.As part of the first step you should keep the initial test as simple as possible. For example if an input to the system under test (SUT) takes a Foo object, just instantiate Foo. Don't start setting values or fields on Foo. Let the fail…

Reinvent the Wheel, Often

We are often never told to reinvent the wheel. In other words, if your job is solve problems within Domain X you shouldn't spend your time recreating or solving problems that fall outside of this domain.For production code, this I agree with this statement fully. Software development is hard enough. The last thing we want is to waste resources such as time or money on anything we can get away with not implementing. For example, creating your own web framework is a project within itself. All you'll end up with is a slow, buggy, badly implemented version of a web framework that happens to power your domain. Sadly I have been on the receiving end of such decisions.There are two times however, when reinventing the wheel is a good thing.You can't get the product off the shelfLearning or personal benefitChances there is no web framework, database client, caching layer or so forth that you can use is very slim. Some systems become so bespoke or scale to such volumes that recreati…