Assert First Development

A good programmer writes about 10 lines of code a day. Maybe less maybe more, though it's a very interresting topic leading to names like Barry Boehm and Tom DeMarco, it's not the subject of this post. I just wanted to point out that eventhough undoubtedly useful, IntelliSense, or any autocompletion tool for that matter, is way overrated. A programmer might type in that single line of code of the hour in five minutes, or in eight without IntelliSense. I'm glad we've got that out of the way. Next, if you are a TDDer and don't already use the Arrange/Act/Assert concept, start today and you will never look back. Anyways.

"Assert First Development"[1] is about writing the assert of your test first. This gives you the means to write the act-part in a way your assert needs it, and then the arrange-part as your act and assert needs it. This way you have to think about only one thing at a time. If you do it the other way around - that is from arrange to assert - you always have to think about all three parts simultaneously. You could of course say "I'm very smart and I can think about many things at once", and I believe you can, but you could use all your cleverness to solve one problem at a time, potentially solving things even better. If not, you still haven't lost anything, you just did your job sequentially. But chances are that your assert will be right the first time around, not mentioning your arrange in which you set really only those things up your act needs, and not the things you think your act will need. Only thing you lose is some parts of your IntelliSense, but we already established that it's really not that much of a loss.
One last thought. Assert First Development is another great example of the pull-system: there is never waste produced, we don't setup mocks or fakes or anything we might not need eventually.

References:
[1] Kent Beck: Test Driven Development: By Example

Read full post...

"Perfect is a verb, not an adjective" [1]

Learning new stuff is paramount in our line of work. I know, I know Cobol coders might tell you otherwise, and yeah, cobol coders might be home free, but the rest of us mortals need to keep up with the pace technology dictates. Or at least not to fall behind irreversibly much. Because then you might become the subject of Murphy's law, saying "If a hammer is all you have, everything you see will appear to look like a nail". It seems trivial, yet many software companies' don't seem to be sporting any learning or improving. Employers and employees alike seem to be confident in and/or content with their current experience and skills. Obviously it's extra effort short term to spend time and energy to learn new things, but with newer and better tools and techniques you can deliver better sotfware in shorter time. In fact the benefits and the profit are so plain to see, that it doesn't need any further explanation or examples, but then again this post would be ridiculously short.

Once you start looking up new stuff, or rather - because it might be something old - stuff you don't know, it becomes second nature, and you don't even notice all the advantages it gives you, or the way programming becomes easier with recently acquired knowledge. So it's difficult to pick any one example from our past year but I settled for mocking frameworks.
When we got to know TDD we dived into writing lots and lots of incomprehensible unit and functional tests nobody understood or was able to maintain. Then we stumbled upon mocking frameworks, and how we could live without one, beats the hell out of me now. We started to use Rhino Mocks, but soon enough our unit tests once again started to look like a can of worms, so this time intentionally searching for a cure, we found out about the AAA-concept (it's short for arrange/act/assert, but I can't find the exact link anymore; go google it up!). Finally we learned that we can use the lambda-expression to make our code even cleaner and readable. We learned and learned till unit testing and object mocking is less and less of a technical problem, and we can concentrate more on what we are trying to express and accomplish with our tests.
Again this example it's not even about new stuff, it's just stuff we hadn't known before. Keep learning and remember there are other useful tools than just the hammer.

References:
[1] Kent Beck: Extreme Programming Explained 2nd Edition

Read full post...