This is how I work with my source control system:

First, what do I check in? Logical chunks that work.

Then, how do I check it in?:

1. You start with no local changes (that’s the best way to start the day)
2. Get the latest source from the source control system.
3. At this point you want to be certain that not anyone else have broken anything, do one of the two:
• Have a build server that notifies when there is a check in, if the last check in was ok, then you’re good to go (this is by far the preferred way)
• Run the tests just after getting the latest source
4. Do what you came here for: code. Whenever you have a logical “chuck” of code, proceed to the next step.
5. You want to be certain that what you are about to check in is working: Run the unit tests one last time to make sure your code is working.
6. You have to merge your changes with anything else that might have changed: Get latest from the source control system.
7. Run the unit tests: At this point, you want to be certain that the combination of your code and the code from the repository is not failing anything. (Here it is a great advantage to have a build server that tells you that the source you are getting from the source control is working, so any failing tests you get now are guaranteed your fault)
8. Fix whatever is broken
9. check in (when all tests are green)
10. Repeat

Also note:

• On a general note, do your best not to check in failing code (failing tests, or even not compiling code). Failing code impeeds all the other team members. Don’t you get really annoyed when someone else on your team are messing up the source, and making lots of extra unnecceary work for you? I do not want to be that person.
• Do not, I repeat: do not, check in anything before getting the latest source. You want to make sure that all the latest source (not just yours) are working together.
• Do not wait too long to check in (to check in at least once a day is a good rule of thumb). The longer you wait, the more merging you will probably have to do.
• It is also a big advantage to have a build server that notifies if someone checks in failing code (so you do not have to be uncertain if it was you or someone else that broke the code when you get the latest source)

I am very interested in hearing your experiences with how to work with source control systems, feel free to post comments.

- Tore Vestues

It is about how your entities communicate, it is about where you place your logic. It is about where to place the code. And when you are programming you are putting code somewhere all the time. That means this is one of the fundamental things to learn as a developer.

So, what is it?

The phrasing itself means that you should tell other objects to do things, instead of asking other objects for information and processing it yourself. (”you” are of course an object in this case).

Example: The car dealer

Say you’re making software for a car dealer. You want to create a report that lists all cars for sale that can be distributed to the customers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ForSaleReport
{
    private readonly List<Car> allCars;
 
    public ForSaleReport(List<Car> allCars)
    {
        this.allCars = allCars;
    }
 
    public List<Car> GetAllCarsForSale()
    {
        return allCars.FindAll(car => car.SoldDate != DateTime.MinValue);
    }
}

There is a violation of “Tell, don’t ask” right there:

1

car.SoldDate != DateTime.MinValue

You ask for information (the cars SoldDate), then make a calculation based on it (calculating if the car is for sale). So, what should you have done? You should tell the Car-object to resolve if it is for sale. It is not your concern to figure it out (when you are in the ForSaleReport), your only concern is to list out cars that are for sale, not why or how they are. So, instead of trying to figure things out yourself, you should just ask the car:

1

car.IsForSale()

Be ignorant

It is easier to apply Tell, don’t ask if you think of your objects as ignorant. You give them a responsibility, and beyond that they should be totally ignorant. Always ask someone else to solve the problems. This makes them ask less questions. Asking less questions means less coupling. Only caring for a single concern means higher cohesion.

And if I don’t .. ?

Didn’t you see the major difference between the two (asking for the SoldDate versus telling the car to figure out if it IsForSale)? Well, there is a difference, and normally it doesn’t take long before it shows.

Say you ask for the SoldDate (thinking Tell, don’t ask are for stupid programmers that wouldn’t understand as advanced logic as yourself..). And say that since this application is growing big you ask for SoldDate several places to resolve if the car is for sale (I’ve seen systems where asking for such “innocent” information is done hundreds of places). Then one day the owner of the car dealership comes to you, quite agitated, telling you that your reports are plain wrong: “A car doesn’t have to be for sale even though the sales date is not set. It can be held of or be in for repair. Fix it now!”

Hm, now you have to search for all the places where you did your “innocent” information asking, changing it everywhere, and test it to see if you broke something else. Pray that you do not have any indirect references to SoldDate (getting it from a car and sending it away for processing further away), that would be hell to track down. Wouldn’t it be better if you just had to change the logic in one place? in Cars “IsForSale” method? I would think so.

And that is not the only problem. Opening up a class, exposing information (like SoldDate in this case) makes it easier for other classes to hard wire itself to the class. This means more coupling, and more coupling means that the class will be harder to change. In this case, there is no way you easily can change the representation of SoldDate within Car. If you want to change it, you have to change every class that refers to it. This might be a very tedious task.

Another problem, which might not be so obvious since there is no “principle” attached to it, is the developer experience: How easy it is to write code in this system. I find this an important issue, and a bit underestimated at times. This is important because it has to do with productivity. When writing new code for this system, and you have to find out if the car is sold or not, it would be much easier just to write “car.IsSold()”, then it would be to actually have to find out how to calculate it, and then implement it (find somewhere else in the code that calculates it, copying that code, and so on…). Figuring out if a car is sold or not should be done once. When it is figured out and implemented, everyone else should just reuse that logic, never again caring for how it is implemented (unless of course, you have to fix or change something in that logic).

Conclusion

For me, Tell, don’t ask brings with it several realizations about programming:

• It is important to think about your modelling when you write code. Where you put your code has major implications on your softwares maintainability.
• Modelling isn’t just for “architects”. As a developer you make decisions every day that can make or break the software.
• Focus on responsibilities, and who should be concerned with what. This makes your application more cohesive and less coupled.
• Don’t repeat yourself (DRY). Tell, don’t ask helps you put logic one place (where its concern is handled) instead of scattering and copying it all around.
• When modelling, it is also important to consider how easy it is to read and use the code for the developers.

So, if there is only one thing you want to keep in the back of your head when programming, I suggest it is Tell, don’t ask.

- Tore Vestues

Let me give you an example.

When Kent Beck and his extreme programmers started out (with XP – extreme programming), they were talking about not writing comments in your code. And they explained what they meant: Comments are often an indication that your code isn’t readable on its own, the fix is often to write code that is easier to understand, not to add comments.

For me this is great advice. I try to keep my code clean and readable, and when I feel the urge to write comments, I first check if I can make the code more self explainable on its own. I personally write some comments, but never to explain code that looks like crap.

The problem with this advice is that it is actually bad advice if you do not understand why you should follow it. Those that do not understand why they should reduce their amount of comments, but still dig the idea, are probably writing as unreadable code as they always did, but now explaining the mess with even less comments. The result is probably all over worse code than if they didn’t follow the advice in the first place!

There are at least two lessons to be learned here.

First, if you do not understand why you are doing something, you are probably doing it wrong. It is time to start questioning what you are doing, always ask why.

Second. Say too many people misunderstand the purpose of something, thus applies it wrong, and thus is actually producing worse results than before. In our “no comment” example, people would, based on empirical evidence of the practitioners, say that the “no comment”-idea is a joke (since most of its followers are actually writing worse code). So by applying the idea wrong you are probably discrediting the whole idea.

I like to define agile in one sentence: “Ask Why”. “Why should we write this piece of documentation?” “Why should we follow this process?” “Why should we follow this practice?” If we better understand what we are doing, and can adjust our practices accordingly, I think we will get a long way. I think this is the core of agile.

- Tore Vestues

Unit tests specify
There is a lot of functionality (or business logic) that is accidental, meaning that it is not really necessary and it might even be plain wrong, a bug. It happens, a lot. It is hard to know if a piece of code is accidental or not if you do not have a way to express it. A unit test is a great way to express your intent and your “real” functionality. For me, unit tests are specifications. They specify the intended functionality. This is explicit functionality. I love explicit functionality. In fact I love almost anything explicit when it comes to code. I want to read loud and clear what the intentions are. The opposite of explicit functionality is of course implicit functionality. This is the functionality that resides in the code without anything or one to claim its importance. Implicit functionality might always be accidental, and that is why it is so hard to work with that kind of functionality. You do not know if it’s supposed to be there.

Unit tests verify
If all important functionality is ensured with unit tests, you have your safety net. The unit tests verify what you specified. Then refactoring is a dream. Keeping the codebase neat, up to date and clean is easy. To be able to nurture your codebase, through refactoring, you will need this safety net. It verifies your intentions and ignores all unnecessary code.

Unit tests do not test software
This way unit tests ensures that the intended functionality in your classes stays there, and makes it easier to refactor. But it does not check if your system work. It does not verify that you have put it all together the right way. It does not check if everything goes right in the databases, on files or in the user interface. Partly integration tests will do this job for you, and partly manual testing.

Abstractions through OO
When I talk about unit tests, I consider my units to be classes. I also want to stress the point of knowing where to put your logic. Responsibilities should be placed where it belongs, in the right concepts (on the right classes). This is the fundament of object orientation, expressed elegantly through domain driven design. The concepts are the classes. Thus it is very important to verify the logic where it belongs, on the classes. And why should we use classes and separate logic? There are mighty reasons for this, but for now let me just say: to avoid cognitive overload.

You need all types of tests
So, unit tests are there to specify the behavior of the systems concepts (think DDD). This is imperative to be able to refactor the core of your system. But as I’ve said, this is far from enough to test your system. I find integration tests best for testing your software. Tests that are more like acceptance tests, checking a complete path of calls from top to bottom (and yes, I often include the database in these tests). In addition there are things you will not be able to test automatically (that easily). How does the gui look and feel? You need someone to test that too.

To conclude, you need a whole lot of unit tests to lock down functionality. You need integration tests to test your software, and you need people to test gui and other stuff that isn’t feasible to test any other way. And my opinion is that you should do all this before you send it to QA.

-Tore Vestues

Disclaimer: There are several reasons software projects fail and many of them are caused by management – way above the developers. Still, we as developers have to take our part of the blame, and crap code is our contribution to the failure.

It is not about algorithms and performance

I didn’t learn much about communicative code at the University. And I still do not think people learn a lot about it. Students probably still think that software development is all about performance and effective algorithms. I’m sorry, often it’s nothing like that. In most business applications today there are no fancy algorithms. It’s just a huge amount of code that is trying to express the rules and logic that exist in the business. Performance might be an issue, but it has nothing to do with tweaking algorithms, it’s about architecture, data loads and sometimes really bad code.

So, what’s the problem?

The major problem with business applications today is the huge amount of code. The amount is not a problem in itself, but it gets to be a problem very fast when it’s hard to understand what it does.

Let’s take a simple example: Methods in today’s software are often way too long. It takes a lot of time to understand 100 lines of code that does several different things, and it’s even harder to change it without breaking something. I’ve seen tons of code that looks like that, and I’ve spent ages fixing such code. Believe me, code like this is very expensive and it will soon be full of bugs. Such software deteriorates pretty fast, and before you know it you’re at a point where whenever you remove a bug, you add two new ones. We should all be ashamed, honestly.

Code that is hard to understand is hard to change; software that is hard to change will be expensive and slow to change, and the risk of the changes adding new bugs is high. Who wants an application where it costs a fortune to add features, takes forever, and adds new bugs?

It’s about communication

Yes, it is a mess, but what can you do? We have to understand that writing software is about communication!

Put simple: Code that is easy to understand is easy to change. When it’s easy to change the risk of introducing bugs is low. That’s the kind of software your customers want!

Martin Fowler hit the nail on the head when he said:

“Any fool can write code that a computer can understand. Good programmers write programs that humans understand.”

What can I do?

When I write software, my main concern is actually if I am expressing my code in a way that others will be able to understand. And the “others” are quite often myself. When I get back to code I wrote two months ago I want it to be really easy to both understand and change that code.

When I have to work with code that is hard to understand I often make it easier to understand first, then make the changes. I keep my methods short. I keep my classes short. I try to organize my code so that related logic is grouped together, and unrelated logic is separated. I write tests for my code that explains the code. I care about the code I write.

Writing code that communicates is first and foremost a mindset. Get it! Then it is a set of practices and principles. Read them, train them and practice them. Find out what works for you. Nothing can replace experience.

Robert “Uncle Bob” Martin has written an excellent book on the topic: Clean Code. Read it now! Kent Beck is also passionate about this, and wrote this book: Implementation Patterns.

I’m holding various presentations about what I call Code Quality. Communication is a vital part of that.

- Tore Vestues

This distinction is not just a play with words, it is important to understand what the practice of refactoring is.

When I stress the importance of the practice of continuously refactoring the code base, it would make no sense if you thought I was talking about changing requirements. When I talk about refactoring and its importance, I talk about code quality.

Refactoring means to enhance the code quality of the system. It is probably the single most important practice to prevent code rot and design debt.

That’s a major distinction.

Fowler defines refactoring this way: “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”.

Everyone should know of this practice, understand what it means, and understand its vital effects on the code base.

-Tore