This is a short reply to a blog post by Ward Bell where he is challenging the idea that all methods in the .Net Framework should be virtual by default. Ward states that by making all methods virtual by default you actually loose control over your classes, meaning that other developer can overwrite all the functionality of any class and not just the parts that have explicitly been declared as virtual. Jeremy Miller replied on Twitter saying that developers should have sharp tools to work with.

This discussion could be extended by the discussion about the fact that Microsoft and other software developers make a lot of the functionality internal or private, protecting the developers who are using the software from making changes to parts of the framework that are subject to change. Stating that the public API should be backward compatible and by making parts internal or private they reduce the risk of breaking backward compatibility. Jeff Handley wrote a blog post about this in response to a blog discussion initiated by Jeremy Miller a while back.

So let’s talk about protecting developers from them selfs; I think this is the wrong approach, instead of protecting we should be teaching the developers to understand that they are working with sharp tools. Take a look at another profession where they work with sharp tools; carpenters work with sharp tools every single day. When they are an apprentice they don’t get a dull saw or dull wood chisel, no instead they are educated on the fact that these are sharp tools and how to properly use them, without loosing valuable body parts. This approach seems to be working for quit some time now.

So why doesn’t this happen in our profession? Why don’t we properly educate our apprentice developers so they know they can’t just do anything with the frameworks they use?

And why not define a specific API for your framework and warrant that this will be backward compatible, also mention that the other parts of the framework are not being considered backward compatible, and that no effort will be spend on trying to keep them so. Provide clear extension points to your framework, don’t mix behavior that should remain with behavior that can be altered. Perhaps a better way would be to split this up and put the behavior that should remain behind the public API? This way normal usage of the framework would be fine and would be backward compatible, but when needed the developers have the power to make changes inside your framework knowing very well that you may decide to change these classes at your own will, without having to explain yourself period.

You could also have unit tests specifying the behavior you rely on, when developers want to extend your system they can run these unit tests to verify that they have not broken some important behavior.

Now let’s go back to having all methods be virtual by default, lets assume this true and instead of the virtual accessor we would have a real or notvirtual accessor so you can specify that this is behavior that you don’t want to be replaced. Would that not be sufficient so serve both scenario’s?

Jimmy Nilsson walks us through what it means to use Domain-Driven Design for your software developing practices. And he does this in a very pleasant way, the whole book reads as if it is one big story being told. Making several jokes along the way, for example I could guess what car he drives by his search criteria example (I was correct Btw). I haven’t seen many other writers use this writing style, but I liked it a lot. This does mean that this is not so much a reference book.

Now as the title indicates this is not just a book about Domain-Driven Design, Jimmy also does a great job in introducing some useful principles and practices along the way. And mentioning many more by referencing many times to Domain-Driven Design by Eric Evans and Patterns of Enterprise Applications Architecture by Martin Fowler. By doing this he really encourages the reader to also read those books as well. I already have those books on my reading list, but otherwise they would have been on there after reading this book. If a book encourages you to continue learning other things than that is to me a success story.

I would highly recommend this book for developers that want to start learning Domain-Driven Design, but also for developers that are new to the trade of Software Development all together. It is a great getting started book on good development practices and principles.

Amazon link: Applying Domain-Driven Design and Patterns

In my previous post I mentioned that some of you are displaying signs of having issues with YAGNI. The YAGNI is some sort of mental illusion that is very common in developers, this illusion mostly affects your ability to produce quality code. And as you may have read in my previous post that is what is most important for a developer.

So what is YAGNI, well first of all it stands for “You Ain’t gonna need it” which is the name for a principle that states that; “a developer should not add functionality until it is necessary”. I like the way Ron Jeffries describes it even better; “Always implement things only when you actually need them, never when you just foresee that you need them” (both quotes are roughly taken from wikipedia).

Ok that is simple, just don’t do anything you don’t have to do. Well apparently this is harder for us creative guys than it seems, tell the same thing to someone working in a factory or anywhere else and they will look at you as if you where an idiot. Why in the world would they do something other then what they have been asked to do? For example you go and pick-up your newly ordered car and the sales person tells you, “Yeah the guys in the plant added an extra steering-wheel for you, just in case you would want go to Australia”. Not gonna happen, but we developers are different, we almost always add this extra steering-wheel to our software.

Maybe this is not entirely fair as we would not actually add a second steering-wheel to a car, but the number of times YAGNI is violated is still very high. The violations are usually very subtle and don’t seem very harmful and Hey we only do it to help out our client right? We would never spend the extra time on something if we didn’t know they would need later on.

But how do you know? How can you tell with certainty that what you just added is actually what is needed later on? You can’t! Even if there is a clear requirement, the code base might change so much over time that you will need to rewrite your solution. And if there is not even a clear requirement then why are you working on it? This is working on assumptions.

What is an assumption? I like this answer on a Yahoo forum; “An assumption is when you like to think you are right, but guess what? You are wrong! It over looks facts and goes on one’s own prejudice of facts”. Or in my own words “You Are Guessing”. Now that sounds a lot worse then saying, we added this and that because it is almost certain that we need it later on. But it is the same thing, just different wording to describe the same behavior.

So why is this bad? Well because if you spend x number of hours thinking, implementing and testing the functionality (lets assume you have actually been thinking about it and have properly tested it). And it turns out that it is not needed, or needed in a different way; then you have been stealing from the project / your boss / your client. If by any chance your guess about the functionality was correct then you have been lucky. Is that really how you want to work, do you always want to guess what you should build, I don’t because the chances that I make the right choice time over time again is very small.

And the added code will drag you down, when ever you need to make a change or extend the code this added code will be in your way. You will have to maintain it as well, some changes will be harder to implement because of it. And all this without any added value! That is right it did not add value, because it is not what was needed.

I have seen this time over time again; It is always easier to add new code then it is to change existing code! Period

So what can you do about it, how do you stop yourself from acting on these illusions? Well the first step, as with any problem, is to recognize it. Start thinking about the functionality you are creating, and always ask yourself the little question; Is this YAGNI? And be honest to yourself, if the answer contains something like this (list is not conclusive); “It might”, “Maybe”, Later we need” or “Cool” then you should wary! Then when you conclude it is indeed YAGNI then you just need to say; “Not Gonna Happen”, not yet anyway. This requires self discipline and good knowledge of the tasks you have to fulfill, but it is definitely an achievable goal and I encourage you to pursuit this goal.

If the functionality that you concluded is YAGNI is indeed very interesting then this should be discussed with the stakeholders and when they conclude it is indeed then it can be made into a scenario for you to create at a later date. The difference is now you know what is needed.

Now here are two more very interesting blog posts about similar misguided practices one by Scott Bellware and a follow up on BlogCoward. You should read both of them!

Many of you (yes you) have the weird notion that the functionality you create is actually the product you deliver to your stakeholder, and that is where you are wrong! Sure the needed functionality and behavior is the reason why you are programming, al do some developers don’t need a reason to code, we call this behavior YAGNI.

So if the functionality and behavior is not the product you deliver, than what is it?

It is your CODE.

And you know what? I need to be able to give your code to any other developer and they should be able to just pick it up and start changing and extending it. This means that by definition it is important that your code is readable and understandable; and no this does not mean readable and understandable to you.

Readable and understandable eh? So I’ll just add comments to the code to explain my intent, that should do it. Wrong again, if you feel the need to add comments to your code to explain what is going on then that is an obvious sign that there is something wrong with the way you wrote it. Make your code explain it self, that way it won’t be out of date when you change it.

Descriptive naming

The first step to make your code readable and understandable is to use descriptive names for all your classes, methods, properties and variables. Don’t shorten your names, make them complete. Yes this means that you will have to type a little bit more, intellisense will be a great help here. This also means that you have to actually think about what it is that this “thing” is representing, which in turn improves your design as well.

Keep it small

Keep your classes and methods small, something small is more easily to understand than something big. A good principle to help you achieve this is the Single Responsibility Principle which dictates that a class or method should only have one responsibility. When something has multiple responsibilities then you should split it up in multiple methods or classes. When correctly applied (with a little help of the Dependency Inversion Principle) this will also help you de-couple your code from each other.

Formatting

Try to format your code as good as possible, don’t put to much on a single line, make your indentation correct, don’t suddenly add many empty lines in your code. Formatting will do a lot to display the flow of your code, use it correctly.

Weird logic

When you have some weird logic like some if else statements and for loops which don’t tell you it’s intend very well, try if you can split these things up into multiple private methods purely to explain in the code why you are doing something. Use the method names to make sense of the weird logic.

In the end this is what separates you from the other mediocre developers, this is something that is more important then knowing the latest new technologies (al do some of these latest new technologies may actually help you make the code more readable and understandable). Good developers write code that functions and behaves correctly, great developers make sure that their code is also easy to be understood by other developers.

Tip: Read clean code from Robert C. Martin
Uncle bob has dedicated a whole book full with tips and tricks (ok tips and tricks sounds demeaning, but really it is a great book that every developer should read).