Consistency: We developers love it don’t we?

We come up with beautiful architectures making sure everything is consistent. If we use a service in one place, we’ll use it everywhere. If we have a ViewModel for showing data, we’ll use a ViewModel everywhere, even if it’s not needed. Because we need to be consistent.

Partly I guess this is motivated because we think that being consistent helps ourselves and teammates understand what’s going on, even if that drives us to YAGNI and a series of WTF’s of why we did something that’s not required. We do it to be consistent!

It might seem inoffensive, but consistency can be damaging. It leads us into trying to homogenize everything despite it not being the appropriate approach in many cases.

So next time someone asks:

…it’s cause we like to be consistent!

Breaking consistency when required not only lowers levels of WTF’s, it can even help scalability!

I’ve been giving talks for quite a while now on best practices, unit testing and other things that aim to make our lives as developers easier. Having myself suffered and lived in a World where nothing was put through automated testing, QA was usually delegated to our customers, and having faced the problems that I and other members of my team encountered when something went wrong on deployment, I’ve truly come to appreciate the value of how certain practices improve my code (and my life). In fact it makes my work more enjoyable. It’s fun. I’ve been on both sides of the fence and I’m on the greener side now. It’s like when you quit smoking (I actually did that too, It’s been 6 years and I’ve not looked back. You can too!).

We loved the songs

I’m now on those greener pastures, running and skipping, with the wind blowing through my hair, freezing my bold head, and singing how unit tests are great and following certain design principles are wonderful. People hear my sing away and they really enjoy it. They love my entire repertoire. They enjoy the dark ballads where I pour my heart out about the pain I suffered during those early days, because they identify themselves with those problems. They enjoy the nice energetic melodies where I talk about how to ease the pain. They see it can ease their pain too. The show ends on a high!

Then it’s over!

This is great and all, but it’s not for me

I was at two of these shows last week. The first one was 4Developers and one of my talks was a short-talk on unit testing with JavaScript. For some reason they had put me on the PHP track,  so I was standing in front of an audience of PHP developers, something I know absolutely nothing about. But it was OK. I was there to talk about JavaScript and Unit Testing.

As usual, to set the context, I asked a series of questions regarding unit tests:

“How many of you know what a Unit Test is” – 80% put up their hand.

“How many of you do Unit Testing?” – 10% put up their hand.

“How many of you think Unit Testing is valuable?” – 80% put up their hand

(rough figures obviously)

Two days before that, I was giving a talk at the Architecture Forum in Madrid, on design principles. I asked a similar question. I got worse results. Primarily because at 4Developers there were roughly 30 people in the room. At the Architecture Forum, there were around 200.

WTF?!

It sounds absurd doesn’t it? Think about it.

“A is good. I like A. I should do A. But I won’t do A”.

People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?

I usually ask this question too, and the typical responses are:

1. Tight Schedules.

2. Decrease in Productivity. Drag and Drop is more productive

3. Customers want deliverables. Tests are not deliverables

and my all time favorite

4. “I’m paid to write code, not tests”.

See, developers live in the real world with tight schedules. They have to deliver to the customer. Their boss and customers are waiting. They don’t have time to do all this theoretical nonsense. In an ideal situation, with all the time to waste, of course they would do all we talk about. But that’s not the reality. They have a product to deliver and this kills their productivity.

What we have here, is a failure to communicate…

For those in the choir on those green pastures, it is crazy. We realize that there is in fact no decrease in productivity. We understand that by taking time to write maintainable code we are making our lives easier in the long run. We appreciate the fact that unit tests allow us to find a higher number of bugs before deployment. We realize that a unit test is not only about making sure our code works now, but that it will also work in the future, and if something breaks, we’ll know about it before we ship it to the customer. We won’t jeopardize the customer’s productivity by stopping his activities because of our failures. Last but not least we also know that unit tests can in fact define our specifications.

Do we fail to communicate properly? Is the Grand Finale missing?

Don’t look at me…

As I mentioned initially, I also didn’t unit test or write maintainable code. So what made me change? Was it a blog post or conference?

Well, I had suffered the issues so I knew I needed to find a better way to do things, and gradually with a lot of time and effort I started to improve how I did things. But it wasn’t an overnight process. And it isn’t over. I’m still at it.

The point however is that I also live in the real world. I’ve had my fair share of bosses and PM’s that thought writing a CRM was dropping a component on a form and hooking up some properties. I’ve had tight schedules and deadlines to meet, but I didn’t throw in the towel with some excuse.

See, all those reasons above are excuses. It’s up to you, as an individual, as a member of a team, to improve what you do. You job involves talking to customers, to project managers, to your boss, to fellow team members and making them understand. Your job doesn’t start and end with writing code. You’ve read that blog post or gone to that talk and seen the value it has to you as a developer. You need to communicate that value to those you deal with.

Your boss doesn’t pay you to write a unit test, of course he doesn’t. But I’m betting he didn’t pay you to write two IF statements instead of one Switch statement either. He doesn’t pay you to comply with the Single Responsibility Principle or care whether you broke the Law of Demeter.

See, what he and your customers do care about is how what you’re doing adds value for them, and it’s your job to not only deliver, but make sure they see that.

Countless times I’ve heard the argument that you should use the var keyword with caution, that it decreases readability of your code, or how it can be misused.

The example given in the linked post is:

    var Data = GetData(); 

According to the blog post, GetData returns a DataTable, something not inherently apparent. The problem however is due to the naming conventions used by the developer.

Firstly, GetData is a method indicating that it returns Data. The problem is, pretty much anything is Data. There has to be a more precise definition of what it is the method is actually doing. By this, I don’t mean you should necessarily rename the method to GetDataTable, since this doesn’t help. This just indicates what type it is returning, not what the method is doing. It would be an appropriate name if the domain of the problem were somehow about types, but in a business scenario, it doesn’t provide much value.

The second issue and just as important, is the variable name, data. Again, it is not descriptive enough. What is data? What kind of information does it hold? Is it a car? Is it many cars?

By using var, you are forcing yourself to think more about how you name methods and variables, instead of relying on the type system to improve readability, something that is more an implementation detail. Using the var keyword is not about being lazy, quite the contrary.

The Dependency Inversion Principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Throw that at a terrible programmer, and all you’ll get is a terrible programmer that is annoyed and hates you. So true!

Take the following method:

        public void PrintHelloMessage()

        {

            Console.WriteLine("Hello");

        }

        public void PrintGoodbyeMessage()
{
Console.WriteLine("Goodbye");
}

or:

{
Console.WriteLine(message);
}

What is Dependency Injection? It’s one way of complying with the Dependency Inversion Principle. However, when you think about it, what does it boil down to? Passing a parameter to a method, which happens to be a constructor. It seems simple enough doesn’t it? Yet, it’s hard for people to understand it. Why? because they don’t see the value in it.

Explaining a principle to someone without them understanding the benefits and values they get out of it is useless, and that is why concepts such as Dependency Injection or Inversion of Control seem overly complex to the vast majority of developers (believe it or not, those of us that use these things are still a very big minority). It’s complex because they haven’t been explained the values of it. They’ve just been thrown some definition and they are expected to understand that it’s bad for one class to create an instance of another class it uses.

Present a developer with the following code:

    public class AuthServices

    {

        public void AuthUser(string username, string password)

        {

            var authDAL = new AuthDAL();

            var user = authDAL.GetUserByUsername(username);

            if (user != null)

            {

                if ...

            }

        }

    }

They’ll probably come up with the solution of passing the AuthDAL class in as a parameter, and eventually realizing that multiple methods will use the same class, they’ll pass it in via the constructor and set it as an instance field. As long as their AuthDAL has virtual methods, they can create any fake DAL that overrides those methods and returns some dummy value. They might argue that they don’t want virtual methods. And that’s fine. Tell them to define the parameter as an interface. In fact, they probably have already heard of a principle that says that you should program to an interface and not a class. They’ll eventually end up with this code:

  public class AuthServices
{
IAuthDAL authDAL;
public AuthServices(IAuthDAL authDAL)
{
_authDAL = authDAL;
}
public void AuthUser(string username, string password)
{
var user = _authDAL.GetUserByUsername(username);
if (user != null)
{
if ...
}
}
}

And voila! You have Dependency Injection via Constructor.

Once they *get* that, then explain to them other benefits, you know the real benefits they get from doing this: decoupled code, easy maintenance, promotion of SRP, etc.  and then throw the principle in their face:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

And they’ll see how it all makes sense.

It’s not about throwing or not throwing books. It’s about showing people how something can help them, how they get value of it.

Busy week for me this week. Between meetings, coding and real bad case of migraine, I've hardly had time to catch up with blogs or investigate new things. However, I did find a bit of time to look at two new tools, one of them being Balsamiq (the other tool, another blog post). I'd heard about Balsamiq some time ago but never really got round to playing with it until this week. And all I can see is that it's damn awesome.

What is it? It's a tool to do mock-ups of UI's. What makes it awesome (apart from the really low price tag), is that it's extremely easy to use and powerful at the same time. Take a look at some screen mock-ups

And here's the iPhone version of the "application"

So in 5 minutes (literally), I threw up a few mock-ups of some UI that I can then show the customer. The cool thing is that it's so easy to use, you can actually have meetings with the customer using Balsamiq and come up with a design together. Here's an image of the the surface design with some random controls:

I remember when I was doing mock-ups years ago using RAD tools like Delphi / Visual Studio. Man does this save time.

Love it! Definitely it's on my must-have-tools list. If you do any type of UI mock-ups, I highly recommend it.

Just a few days left for the Early Bird fee for the iMeta Architecture Days. It's going to be a two day event in Madrid on Design Principles, Testing, and on the second day Domain Driven Design and SOA with Udi Dahan!

Since it's a training event, it's going to be a small group so there's more room for interaction.  And all this is for just a mere 375 Euros. Price includes lunch and munchies on both days.

To sign up and more info, click here

As if what Alt.NET is or isn't, whether it's mean or not, wasn't enough, now we have a new guy on the scene, and already the first reactions on the blogsphere (not to mention mailing lists and twitter world).

Well before I give you my opinion, let me ask a couple of questions:

Have you always written applications that have been bug free?

Have you always written applications that were a breeze to change and changes would not introduce new bugs?

Have you always written applications were the code was easy to understand after not looking at it for 6 months or for a newcomer to the team?

I haven't. I've worked on applications were I used to not sleep a day before a new deployment, not knowing whether those last minute changes broke something. I've picked up applications that took me weeks to figure out. I've been on projects of 7+ people were the bus number has been as low as 1, both as a developer and as a stake holder. I've learnt from my errors and I am continuously trying to improve the way I develop software to avoid making the same mistakes I've made in the past.

Unit testing, Test Driven Development, Dependency Inversion, Single Responsibility aren't required to make your software work. You don't need them to deliver applications. Your applications will still work without them. You can still link business logic to partial classes of datasets or hook them up directly to code-behind files in your ASPX pages. You can still use databinding with ObjectDataSources and your application will still work. You can still ship software that will work well for millions of hours with hundreds of thousands of users connected to it.

However, I'm quite certain that you'll suffer the consequences. I'm pretty sure, having been on both sides of the fence, that it will be easier to make a change to an application where you have a clear separation of concerns as opposed to the drag-and-drop version. It will be more re-assuring to make a change and have 90% of your unit tests pass, fix the remaining 10% and then deploy, as opposed to just ship and hope for the best.

That's why I write unit tests, to try and catch as many bugs that I introduce when making changes to existing software. That's why I apply principles such as SOLID, to make my code easier to change and more understandable

Alt.Net or the recent manifesto of Software Craftsmanship for me represent ways to improve my job and myself. Ways to develop software that will make it easier for me. At the end of the day, what I care about is what I'm responsible for, and that is myself, my team and the software I write. It's not about making a statement or trying to change the world. Another matter is if I choose to share my experiences with others, which I'm free to do. But it's not about forcing one way over the other.

Maybe the ways that I've learnt to improve up to now are not entirely correct. Maybe tomorrow we'll find better ways to write software, to make our life easier. However, I know that what I'm doing today is better than what I did yesterday. But that can only be accomplished if I'm willing to accept that I don't know it all and I'm open to improvement.

According to you Jeff, 80% of developers are people that don't care much about improving the quality of their craft. In other words, it's mostly those who just care about the paycheck...programming is a job that pays the bills.

The remaining 20% fall in the category of those that read your blog (note the part in Italics):

But here's the paradox: the types of programmers who would most benefit from these guidelines, rules, principles, and checklists are the least likely to read and follow them. Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off. This is something I discussed previously in Mort, Elvis, Einstein, and You:

Thus, if you read the article, you are most assuredly in the twenty percent category. The other eighty percent are not actively thinking about the craft of software development. They would never find that piece, much less read it. They simply don't read programming blogs-- other than as the result of web searches to find quick-fix answers to a specific problem they're having. Nor have they read any of the books in my recommended reading list. The defining characteristic of the vast majority of these so-called "vocational" programmers is that they are unreachable. It doesn't matter what you, I or anyone else writes here -- they'll never see it.

In the absence of mentoring and apprenticeship, the dissemination of better programming practices is often conveniently packaged into processes and methodologies. How many of these do you know? How many have you practiced?

Yet at the same time, as author of this blog and thus falling in the 20%, you state:

All those incredibly detailed rules, guidelines, methodologies, and principles? YAGNI. If it can't be explained on a single double-spaced sheet of paper, it's a waste of your time. Go read and write some code!

So which is it Jeff? Do we or don't we try and improve ourselves?

I don't fall into either of the groups, I'm not a Coding Horror. I'm one of those guys that tries to improve my knowledge, I try and learn continuously, either by myself or with the help of those that surround me. I don't just throw it all out of the window and claim that if there isn't a mentor around to help me, screw it. I don't give up if I can't understand it in a few hours. If others do differently, I try and understand why they do it differently. 

To claim that I'm not going to need to, or not change my ways is very arrogant on my behalf. And the best thing is that I'm not alone. There are thousands of others like me.

So please Jeff, don't corrupt the profession just to justify your own ways.

[And to my reader (Hi Mom!), I will do my utmost best to refrain from writing any more posts about Coding Horror]

My mother wants to become a computer programmer (not to be taken literally). And guess what, she can. With all the RAD environments nowadays you really don't need to know much about the basics of programming to make applications. You can use anything you want. First step, pick an environment. You have lots to choose from (Visual Studio, Delphi, Ruby on Rails). In under 1 hour you'll have your first application working. Next step, sell it.

Now do this for about 10 years, making a profit and you can claim that you're successful in software development. You can claim you've worked for 10 years and have never had to worry about things such as polymorphism, delegation, etc.

So when someone comes along with a post talking about weird things such as SOLID or how rules are meant to be broken, you reaffirm your position as a successful developer that has never needed or understood these concepts. And since the person writing this has 1.5M visitors a month and 125K subscribers, it's OK!

(You think I'm crazy. Read some of the comments on this post).

But It's NOT OK

I don't lose sleep over what I term demoware cowboys. Everyone has a right to make a living, however way they want. I'm the first person in the room that stands up to defend not needing to graduate in CS to have a successful career in software development. However, I also defend studying, understanding and practicing software engineering, and to continuously improve yourself. Just because you sell software and put food on the table doesn't mean you've accomplished all there is to in your field.

What does bother me however is people talking about things without truly understanding them. It's important to act with responsibility, specially when having so many followers.

Some of us write software for a living, as opposed to just writing about it,  and it's not only about getting the job done.

Take a look at this code:

   1: public class ClassToTest {

   2:  

   3:     public void MethodToTest()

   4:     {

   5:         

   6:         IDAL dal = new DAL();

   7:  

   8:         int discount = dal.GetDiscount();

   9:  

  10:         if (discount > 10)

  11:         {

  12:             // Do something

  13:         }

  14:  

  15:     }

  16: }

The tight coupling to DAL just stands out like a sore thumb. One consequence of this tight coupling is that it's hard to test if we don't have an underlying database setup with correct values. Forget about testing this while taking a shower, unless you have a habit of taking your SQL Server box to the bath tub with you.

Take a look at the following approach to making this code testable without having a database:

   1: public class ClassToTest {

   2:  

   3:     public void MethodToTest()

   4:     {

   5:         

   6:         DAL dal = new DAL();

   7:         

   8:         #if testing_in_shower

   9:         int discount = 3;

  10:         #else 

  11:         int discount = dal.GetDiscount();

  12:         #endif

  13:         if (discount > 10)

  14:         {

  15:             // Do something

  16:         }

  17:  

  18:     }

  19: }

Are you still here? Didn't you just fall off of your chair, not knowing whether to laugh or cry in anguish? It's just plain wrong isn't it? Code Smell just takes on a whole new dimension (and consistency?). Something like this shouldn't be done for many reasons. It makes our code testable but it's wrong.

Introducing code for testing purposes

The reason I bring this up now is because in the past 2 weeks I've seen a few references and examples of introducing code just for the sake of testability. Two weeks ago I was skimming over an article that was explaining unit tests. The class the author was trying to test had a dependency that was causing issues during his tests. The solution offered was to introduce a new constructor and inject the dependency in. In our case, the ClassToTest would like:

   1: public class ClassToTest {

   2:  

   3:     public ClassToTest()

   4:     {

   5:         

   6:         // Initialize some stuff

   7:  

   8:     }

   9:  

  10:     public ClassToTest(IDAL dal)

  11:     {

  12:         // Initialize some stuff

  13:         _dal = dal;

  14:     }

  15:  

  16: ....

Now that's great. The problem is that the author left both constructors in there, emphasizing that one is for testing purposes and the other for production code. Why that's wrong I'll get to in a moment.

The other day, Scott Hansleman made a blog post on testing some code that had a dependency on the current principal. His solution was to inject IPrincipal into various methods of the Controller, where Controller is in the context of an ASP.NET MVC Controller. Personally I don't agree with the solution but that's another subject (and another post on a different approach I have in the backlog for the same scenario). However, injecting the dependency seemed valid enough. Later on he updated the post with the following:

UPDATE: Phil had an interesting idea. He said, why not make method overloads, one for testing and one for without. I can see how this might be controversial, but it's very pragmatic.

1. [Authorize] 
2. public ActionResult Edit(int id) 
3. { 
4. return Edit(id, User); //This one uses HttpContext
5. } 

	[Authorize]
	public ActionResult Edit(int id)
	{
	return Edit(id, User); //This one uses HttpContext
	}
	

You'd use this one as before at runtime, and call the overload that takes the IPrincipal explicitly for testing.

The same thing has happened as in the case of an overloaded constructor. Code has been introduced into the base just for the sake of testability. In the previous case it was a new constructor, and in this case, a new method.

Why is this wrong?

Introducing code just so that you can test it is wrong for several reasons, including an increase in noise, decrease in readability and more importantly, permitting the possibility of production code that will not be tested. It might seem improbable at first, seeing that the overloaded versions always call the base ones, but as your code base grows, by allowing this habit, you can promote it to other structures such as conditionals, switch statements, etc, and not limit it only to methods or constructors. Then you'll start initializing values that only make sense in tests and gradually your code starts to smell more and more. To top it off, you can throw in some compiler conditional that rips those parts of the code out from the production version.

Code should also serve as documentation. The cleaner you make your code, the less noise and redundancy you add, the easier it is for others to understand and maintain.

Conclusion

Being pragmatic is good, but don't do it at any cost. Try and not introduce code into your code base that is there exclusively for the purpose of testability (and no, dependency injection is not only for testability). Anything that has to do with testing, keep it where it should be, in the test assemblies. Having overloaded methods or constructors, mocks or stubs in your code base is just as bad as having compiler conditionals in your code for testability. If you run into issue where your code is hard to test, step back and re-think your design. Maybe the problem you're facing now that's impeding your tests is actually a can of worms waiting to be opened. And the sooner you open it, the better. That's one of the great advantages of Test Driven Development.