I've recently had a number of discussions with various different people around consistency.

There a few really good reasons why you should be consistent in your development approach. Being able to pick-up a code-base and understand where the tests are, where external libs are stored\reference and how to build and run are fundamental when you work on more than one project. In a similar way, being consistent with setting, both application and keyboard (ReSharper) can increase productivity when working with a team as it makes it easier to share the code and pair at different machines. Having a standard and a foundation gives you the base to improve and learn from. Toyota have said “standardized tasks are the foundation for continuous improvement and employee empowerment” Wikipedia.

However, this brings about another problem. If you are continuously improving, what happens to consistency?

Many moons ago, we were all writing our data access logic using Ado.net and code-generated ORMs. Thankfully today we have NHIbernate. We have taken a standard, improved and progressed beyond it to create a new standard. This is why consistency is overrated. If we were consistent, we would had kept making the same mistakes for the sake of being consistent. The same can be said for unit testing frameworks, languages and even project structures\coding style.

However, in software many people forget the improve and progress part once a standard has been set.  We sacrifice improved productivity and adding value to the business to maintain the status quo. How many developers would push the use of frameworks like OpenRasta instead of just going with ASP.Net MVC because they did ASP.net webforms before - even when OpenRasta provides a much better solution to their problem. Or use WCF because “we are a Microsoft shop”, hence must be consistent and use the Microsoft stack.

Get a grip.

Forget consistency. Instead, focus on what makes you productive, what provides value and what makes doing your job easier. If there is a better way, do it and break free from the status quo.

Labels: Development

A while ago I was on my way to see family members. Due to working all the time, I was unfamiliar with the route so I used my GPS. During the journey I had a brainwave, a good GPS system is like a good software development team.

Imagine the roles involved in a car journey. We have the nice GPS lady, the one who knows the final result and the most effective way to get there. We have the passengers who do the work together with the backseat drivers who think they know better than everyone else involved and will take you in a different direction.

This is very similar to the structure of most project teams. Everyone knows the final destination, and some might even know how to get most\part of the way there however we have project managers guiding us along the way, step by step, even if sometimes they are just background noise telling you what you already know. We have developers\testers taking the information from the project manager and applying it using their own skills. The GPS doesn’t drive the car in the same way project managers don’t write code. Finally, we have the members of the team who always seem to know better - these are either visionaries or bad apples.

As you are driving, when you are coming up to a change in direction the GPS will tell you just enough information to put you in the best position to act when the additional information is relevant instead of overloading you with unnecessary and confusing the problem right at the beginning. As the steps are broken down and told as required, if you go wrong then the GPS can adjust itself and guide you back. These could be consideration iterations.

What if the journey wasn’t broken down into steps? You would know the end route, however you wouldn't know the quickest, or even how, to get there. Instead you would be flooded with information as soon as you enter in the car. You will be told every turn taken, every lane change. During the journey, you will attempt to remember everything, as a result relying on other indicators such as traditional sign posts. The problem is that you can easily miss a critical step and take a wrong turn. Without someone guiding you, you could be going in the wrong direction for a long period of time. This is the equivalent of a waterfall project and we all know how they end. GPS systems take an agile approach to car journeys.

But I only have a cheap GPS systems. The good (ie expensive) GPS systems respond to the environment around them.  They can sense (be alerted) to traffic ahead and as a result take a different route to ensure you get to your end goal in the most effective way. This is why you pay twice as much, as when problems occur, they can help instead of just sending you down the same old path.

I think this is the same as a good project manager. If they can see the problems coming, then they can guide the team without the team ever knowing or being distributed. This allows the team to stay focused and motivated while the project manager does the hard work of ensuring any problems don't affect the project. This is a powerful and extremely useful position and person to have. This is when both GPS systems and project managers justify their cost.

But what if you crash? Well your project just got canned and no matter how good your GPS\pm is they can't help.

Interesting what comes into your mind during a car journey.

Labels: Random

When creating test names, I use a BDD style naming convention to describe the behaviour being tested. As such, I like the naming to be in a particular, consistent style. For example:

However, as you can see Resharper is saying there is a problem because of the way the method has been named. Ideally, Resharper should allow this naming convention. With Resharper 5 (maybe in 4.5 too), you can change the setting to match how you want your naming to be.

Simply by hitting alt+enter you have some options related to Inconsistent naming.

In the settings dialog, you can set the name style. In my name, First_upper is how I like my tests to be named.

Resharper will now accept the naming. As a bonus, if the name happened to be Something_Like_This() then it would detect and provide an option to convert the naming to Something_like_this() keeping your test naming consistent which improves readability. Very cool!

However, the problem now is that ReSharper complaints on production code. For example:

Luckily, you can define two possible naming conventions as I’ve done below.

Labels: ReSharper

This week Google was kind enough to invite me to "Google Apps Premier Edition". This is the email:

I would love to use the premier edition as the free version is amazing! Sadly, the invitation was only for the 30 day free trail. After gaining my interest, Google then went and lost my interest while also making me disappointed. Not the ideal way to make your users feel.

When sending over promotional emails, take into account how the user will feel and their thought process when reading your email.

Yesterday was the excellent DDD8. Thank you to all who attended. I gave a grok talk and a full presentation. The grok talk was on Albacore,  while the full presentation on Testing ASP.net Web Applications using Ruby. The slides are below. If you have any questions\feedback then do please let me know.

Don’t forget, if you are interested in learning more about Testing ASP.net then my book has recently been released.

Download demo from http://github.com/BenHall/Kona/zipball/DDD8

Labels: DDD, DDD8, TestingASPnet