Skip to main content

Posts

Showing posts from February, 2014

TDD is a Tool

I remember being introduced to Test Driven Development (TDD) very well. This is because it had such an overwhelming change on how I write code day to day. It was incredibly alien, difficult, yet rewarding. On this journey for the last five years I've changed my style, learned how not to do it and finally found my "sweet spot" when it comes to pragmatic TDD.Deliver ValueWriting code is fun. Developing an application or system is fun. Using new technology is fun. Despite this the end goal should always be to deliver value. Delivering business value over religiously following a practice was a turning point in my journey. After all the user doesn't care about what is behind the scenes, as long as they can use your software, they're happy.When to Write Tests?One of the guidelines when starting TDD is"Never write a line of code without a failing test" - Kent BeckThis rule is wrong on many levels. Firstly it cripples most developers when starting TDD. Secondly…

The Correct Way to use var in C#

The .NET community is not widely controversial, though there is a strong topic that appears to come up time and time again when I pair with other developers - how to use var in C#.The var keyword was introduced in .NET 3.5. Unlike other languages this is still a strongly typed declaration. For example if we declare a string using var then we cannot re-assign this variable to another type. This would be a compile time error.There are two parties who have strong feelings about the use of var, both of which are wrong.Never use varSome developers suggest the use of var be denied. This leads to code such as the following. Overly verbose, and in some cases obscuring the intent of the code. This can commonly be seen when dealing with collections or generics.Always use varOther developers claim you should "var all the things". This leads to code which has the opposite problem from above. The intent of the code can be obscured due to not knowing what type you are dealing with. This i…

Top Down vs Bottom Up

Top down development has you starting at the highest point in the application that you can. From here you code down until there is nothing else left to develop. Once you reach this point you should be code complete. Along the way you may need to stub out areas that have not yet been created, or designed.Bottom up development has you starting at the lowest point in the application. The idea being that this part of the application has the most complexity or will be the most important. You will build the system up from a series of smaller components.Top down development and bottom up development was introduced to myself in my early days of university. At the time the distinction didn't really mean much - I was very much a developer who would work from the bottom up.Over time I have completely switched my stance on this. I believe agile practices and TDD are the reason for this change. I feel so strongly about this that I would go as far as to claim that within an agile team - bottom …