Ndc 2010

I’m very proud to announce that I will be speaking at the Norwegian Developers Conference 2010 (track 6, day 3, 16:20).

My talk is named “A Style of programming”:

“This talk describes a set of coding principles that constitutes a style of programming that focuses on ease of coding, ease of changing the code, and ease of testing the code. The presentation aims at helping programmers understand how the principles relate to actual code. Every principle is made concrete through examples. This style of programming is influenced by leading object oriented and agile developers, and it is perfect for applying on object oriented languages such as C#.”

Hope to see you there!

- 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

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

There are a couple of points I want to make here. First I care about writing code that can be easily understood after it is written. Secondly, I want to express as much as possible with as little as possible. I do not want to write five lines of code if I can express the same thing with just one line of code. These two concerns do of course relate. The keywords here are flexibility and efficiency. And let us not forget writing clean, expressive code is a lot more fun than fiddling with repetitive code: How many times have you written code (more than one line) to loop a collection? And how inspiring is it really? We want to loop those collections as easy as possible.

Languages like Python (and its relatives like Ruby and Boo) has put a lot of effort into making working with collections (or lists) as easy as possible. My main language at work nowadays is C#, and I must admit I envy developers in these languages when it comes to collections.

I actually envy them so much that I’ve been reflecting on how we can make our lives easier as well. With .Net 3.5 there is actually something we can do about it.

Collections in Python, Ruby and Boo

But first let me show you what I envy.

Let’s use a simple example to demonstrate my point: We have a list of numbers where we want to make a sub list with all the numbers bigger than 10. In addition, we do of course want to print the sub list to the console.

Boo (one of the most exiting languages for me these days) will simply do it this way:

numbers = [1,15,7,100,3,4,5,19]
print numbers.Collect ({number as int| number>10})

In Boo, lists have built in functionality for making sub lists. I think this code is beautiful. The elegance (and often confusion for C#-developers not familiar with these kinds of languages) is how you declare the conditions for making the sub list. I won’t go into details about this but what we say here is: for the list “numbers”, take each “number” and add it to the sub list if “number>10″. The print statement is all you need to print the list (in an understandable human form) to the console.

It can’t be much simpler than this. Although I actually like the Ruby-way of doing this a micro-tad better:

numbers = [1,15,7,100,3,4,5,19]
puts numbers.find_all{|number| number>10}

I like the find_all method name a bit better than Collect, and I like that you do not have to say “as int”. On the downside the “puts”-statement is a bit less intuitive than plain “print”. But in the long run these are details (or at least we can pretend it is in this context).

In python you can say it like this:

numbers = [1,15,7,100,3,4,5,19]
print [number for number in numbers if number > 10]

Maybe a bit weirder at first glance, but it’s very concise if you’re used to it.

Ok, the point of this was to demonstrate that it is actually quite easy to express a loop very compact and elegant, and this is where I want to be when I loop collections in C#.

Looping collections in C#

The “this will work in almost any language”-code for doing the same job in C# will look something like this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
List<int> subset = new List<int>();
 
foreach (int number in numbers)
{
    if (number > 10)
        subset.Add(number);
}
 
foreach (int number in subset)
{
    Console.Write(number + " ");
}
 
Console.WriteLine();

It’s outright horrible compared to the Boo-example! It makes me wonder how many times longer it takes to develop a C#-application, and how much less readable it will be.

So what can we do? Well, let’s see if we can make it simpler.

Using delegates

With .Net 2.0, we were introduced to the concept of delegates (function pointers). It’s an odd concept for the traditional C#/vb/Java-developer. Function pointers are very common in some languages (again, typically in Python and friends), but not in “our” languages. Anyway, I’m really happy that Microsoft introduced us to this as it gives us some interesting possibilities.

We can remove a foreach-loop by using the Array.FindAll-method that takes a delegate. The delegate specifies how to filter the array, and then we have a sub list. This sounds a bit nicer. It looks like this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, 
      delegate(int number) { return number > 10; });
 
foreach (int number in subset)
{
    Console.Write(number + " ");
}
Console.WriteLine();

Still a lot of code unfortunately, and the FindAll-method call isn’t really as clear and simple as it could have been either. I won’t go into details about the delegate-concept here, but if you do not understand how it works, I really advice you to take a look. It’s a powerful tool. (Look at my post Delegates, the interface for methods)

Using extension methods

The fact that you can just write “print” in Boo, where I have to write a foreach/Console.Write in C#, annoys me. Let’s fix it.

We could fix this by creating a subclass of Array, and override the ToString()-method. But frankly I do not like the idea. That would mean that everybody everywhere have to use that subclass instead of the standard Array-class. And that isn’t going to happen. There must be an easier way, and it is if you are fortunate enough to be working with .Net 3.0 . Here you can add an Extension Method to the Array-class. Unfortunately you cannot override a method by doing this (i.e. ToString), but you can create new methods on the Array. So let’s do that.

First the extension method:

public static class ArrayExtension
{
    public static void Print(this int[] list)
    {
        foreach (int number in list)
        {
            Console.Write(number + " ");
        }
        Console.WriteLine();
    }
}

And then the main code:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, 
      delegate(int number) { return number > 10; });
subset.Print(); // extension method

Look at that. I’m feeling better now. We’re getting somewhere.

Using Lambdas

I still do not like the delegate-declaration in the “FindAll”-method call. It’s clumsy, verbose, and not enough to the point. Lambdas introduced in .Net 3.0 will help us simplify this. Read more about lambdas here. For us, a lambda is just an easy way to declare a delegate. Look at this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, number => number > 10 );
 
subset.Print();

Sweet! When you get used to it (and you should) the lambda-syntax is very easy to read. And look at how we do not have to declare the types anymore. I really like it. There can be a big difference between how you can do things, and how you should do things. I think this is how you should do it.

Using Linq

Actually, .Net introduces another elegant way to do this, Linq. It has quite a different syntax from most other languages with one notable exception: Sql. Linq treats almost anything like a collection that can be queried. Thus link is in itself a little dsl query language. It’s a great idea, I’ll give Microsoft that. Anyway, this is how our solution will look if we use Linq:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
var subset =
    from n in numbers
    where n > 10
    select n;
 
subset.Print(); // new extension method

Yes, I like this one too. If you know Sql, and we probably all do, this is very easy to read.

Which one of these two do I like the most? To be honest, I’m not sure. I like them both. Feel free to give your thoughts on the issue.

Conclusion

To be honest I still like the Python/Ruby/Boo- way a little bit better, but with lambdas or linq I think C# is almost as elegant.

I want to make two points here:

First, it’s important to evaluate how we write code. We should always try to find ways to express more with less, and in this case we have been given several tools to help us on the way. It’s just up to us to use them, and use them well.

Secondly, do not let a language limit you. Try different languages and look at how they solve problems in different ways. Many times it will inspire you to find new and better ways to use a language, like here where we’ve applied a little pythonic thinking to C#.

- Tore Vestues

The declarative mindset

First, let me specify my viewpoint: My interest in declarative programming is not primarily from a programming language point of view (at least not in this context). I care about it from a programming mindset point of view.

The easiest way to define declarative programming is to say it cares about what to do, not how to do it. There is more to declarative programming (and the languages) then that, but for me this captures the essence, and this is the kind of thinking that can help improve our code.

Example

Let me start off with a little example. Let’s make a menu bar in Html.

 <div style="text-align:right;
    background-color:#dddddd;
    padding-top:2px;
    padding-bottom:2px;
    padding-right:4px;
    border: 1px solid #666666;">
  <a href="home.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;
    text-decoration: underline;">home</a></li>
  <a href="login.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">log in</a></li>
  <a href="news.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">news</a></li>
  <a href="contact.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">contact</a></li>
 </div>

Html is a declarative language in itself, so this is by default declarative. But strict a definition isn’t very useful here. I want to improve my coding, not adhere to a definition. So let’s try to improve this code with thinking “What to do, not how to do it”. What do I really want to do here? I simply want to make a menu bar with clickable items. Nice. And this code tells me nothing about how I do it? Well, it actually does. It tells me quite a lot about how it is supposed to look.

Let’s use a separate css-file to extract the “how it looks”-part from my declarative menu bar-code.

  <div class="menuline">
   <ul>
    <li><a href="home.html" class="current">home</a></li>
    <li><a href="login.html">akvareller</a>log in</li>
    <li><a href="news.html">news</a></li>
    <li><a href="contact.html">contact</a></li>
   </ul>
  </div>

That’s better. Now there is not much “How” left in my menu declaration. It’s mostly “What”: A menu bar with clickable items.

Notice that the css-part is also by itself declarative in the strict definition, but for our usage that information is not declarative when we want to define the “what”-part of the menu bar.  Again, the important thing here is not to define what declarative really means in programming language terms. The important thing is to see how it makes us think when we code, and how that mindset affects the code.

Advantages

This is of course a trivial example, and most of us already separate a lot of looks-code into css-files, maybe even without reflecting on why. My point here is not to talk about how to best use css-files. My point is to reflect on what this “declarative mindset” actually does in a broader sense. In my opinion, it has several positive effects on the code, including:

•  Readability
  • The second coding example is easier to understand than the first. Frankly, the first example is a bit of a nightmare. Code that is easy to understand is flexible because it is easy to change. And let’s face it, it makes a developers life better. We all know that code that is hard to understand is hard to work with.
• Ease of use
  • It should be easy to write code. Writing the “what”-part of the menu bar certainly is easier in the second example than the first. It’s easy to write new code, and it’s easy to change the code. Even the “How it looks”-part of the code will be easier in the second example. It’s tidier.
• Separation of Concern
  • This is one of the fundamental design principles in programming. In our example what we have done is actually to separate the “What”-part from the “How”-part. Thinking this way makes us automatically separate concerns.
• Reusability
  • Of course, factoring out all the looks of a menu bar makes that look easy to reuse elsewhere.

Taking it further

To be honest, I’m still not satisfied with the html-code defining the menu bar. Still there are some list item-tags there that really don’t say anything about what this is. I’m actually also a bit skeptical to the a-tag as it is a bit too technical to clearly define the “What” of this menu.

I want to take it further. Now I want the declarative mindset to help me think more in terms of concepts and abstractions. That is what this is about. The more I speak in general terms, in concepts and abstractions, the more I focus on “What to do”. The more technical it gets the more I focus on “How to do it”.

Let’s implement this in Asp.Net and see if we can get any further:

<menu:Menubar runat="server" ID="menu">
  <menu:MenuItem Title="home" TargetPage="home.html"/>
  <menu:MenuItem Title="log in" TargetPage="login.html"/>
  <menu:MenuItem Title="news" TargetPage="news.html"/>
  <menu:MenuItem Title="contact" TargetPage="contact.html"/>
</menu:Menubar>

Remember what we wanted to do? “I simply want to make a menu bar with clickable items”. This code does exactly that, and nothing more. The menu bar has a type that defines everything about its look; the items have a title and a place to go to if they are clicked. That’s all. Now we really describe concepts. The technical “How”-part is completely in the background. The technical details will of course have to be implemented somewhere, but here is the beauty of separation of concern: It is to be implemented somewhere else. When we work with this part of the code, we do not have to worry about it. When we work with that part of the code we do not have to worry about this part of the code.

Bear in mind that this is a mindset and not a language-thing. Separation the “what” from the “how” can be done in any language.

The funny thing about the declarative mindset is that the resulting code looks quite like code that a good object oriented mindset would create. Come to think of it, that’s probably why I like it so much in the first place.

- Tore Vestues

That being said, I have realized that there is something about reusability that OOP is very good at, it’s just that we have been a bit mislead about the general conception of what reusability really is.

The classical definition of Reusability

Traditionally, reuse has been about the reuse of components. Big components. And typically third-party components. Precompiled, general purpose components to solve every task. This is reusability at an architectural level. In a not so far past, when OO-technologies emerged, the industry were dreaming about a future where programming was reduced to assembling standardized components. Now that would have been something! But as we all know, it just didn’t happen.

Still many people believe in this classical idea of “the grand reuse” at some level, but most of the time it just doesn’t work.

It’s time to say: Reusability is not an issue. At least not this kind of reusability. Most projects should not spend good time and money on generalizing everything just a bit more, hoping to get some value from reusability somewhere in the future. Because most often, you won’t.

The actual reuse in OO-systems

So, what’s my take on reusability? Reuse happens a lot! Or at least it should. But it is all happening at the code level. As a developer you reuse when you refactor out common functionality. If your code is called from more than one place, it is being reused. Reuse is the opposite of copying code. Reuse is about factoring out common functionality. Reuse is about writing less code. This should be in the back of every developer’s head at all times. Reuse should just happen. When it comes to this kind of reuse, OO is an excellent tool. Good OO systems implements a lot of reuse. Good developers reuse a lot.

It’s time for business to stop believing the hype, and to start realizing that it’s the quality of their developers that really matters. It’s the developers that implement reuse, and produce the values of it in form of less code, better quality, and more flexible code.

- Tore Vestues

Communication

The more I write code, the more I realize that understandability is one of the key aspects of writing code. Making myself understood. Writing readable code. In his book “Implementation Patterns”, Kent Beck identifies “Communication” as one of the three values “consistent with excellence in programming”.

We should spend more time thinking about what we want to communicate when we write code.

When it comes to naming methods, my rule of thumb is that you’re not supposed to have to look into a method in order to understand how to use it. By looking at the method name, maybe it’s parameters and return value, and considering its context (the class that encapsulates it), I should clearly understand what the method will do for me.

Communicate intent, and intent only

A good method name should communicate intent: What service do I offer, what will I do for you. On a collection-class, a method like

sort()

communicates it’s intent well. Given the concept of a collection, we understand that this will sort the items. Now what about this:

sortUsingQuickSort()

Still we communicate intent, but there are two problems here. We now have to consider how we want to sort the collection when we call this method. Wouldn’t it be better if the collection made this decision itself? The collection should be in a much better position to make that choice. And often we do not care about how, we just want it done. It’s important to make the choices as easy as possible for the consumer of your methods.

The second problem is that we reveal implementation details. In many cases this method says to much about the inner workings of it’s class. A well designed object oriented class, reveals as little as possible about it’s implementation details. We do not want to give away that information because we reserve the right to change the implementation of the sorting later.

No surprises

A method should do exactly what it tells me it will do. Nothing more, nothing less. There shall be absolutely no surprises! Consider this method on a collection:

int size()

I’m sure we all expect this method to return the number of elements in the collection. So if this method actually removed the last element in the collection, that would have been quite a surprise! And of course that would have been a recipe for disaster. Because “all surprises in our industry are bad surprises” (I think Kevlin Henney phrased that one).

This case is obvious, but believe me, I have seen some pretty nasty side effects in methods. Such side effects often appear when you do not consider what the method is supposed to do in general terms, you only think about what it will do for you right now. For instance if this collection-class for the moment only was used one place in your code, and you were two hours from deadline and needed this to work, instead of implementing a queue with a dequeue-method, you just removed the last element in the size()-method. Maybe something like this:

// Warning: example of stupid code 
while (collection.size()>0) { 
  handleElement(collection.getLast()); 
}

This is not the best example because the stupidity of this is so obvious, but there are lots and lots of similar examples that are more subtle but still just as stupid.

Make your methods as trustworthy as possible, do what you promise, but absolutely nothing more. State the intent, and stick to it.

- Tore Vestues

Because allthough it is important to be able to solve technologically complex problems, the genius is to find solutions that helps us remove complexity.

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” – Alan Perlis 

Keep It Simple, Stupid! 

“What is the simplest thing that could possibly work?” is Kent Beck’s (and XP’s) matra. The question truly captures the essence of avoiding over-engineering.

In software development, ”keeping it simple” is important for several reasons: Developing complex code takes time, it is harder to get right, and might be harder to debug. Complex code is also harder to understand, and complex code often means more code. More code means more places for bugs to appear, and more code takes more time to understand. Complex code is often very hard to maintain.

Essencial versus accidental complexity 

Ok, there are complex problems that require complex solutions. These problems must of course  be treated as such. But it’s important to identify and remove what Kevlin Henney reffered to as “accidental complexity” in his talk “With economy and elegance” at Jaoo (jaoo.dk) in september 2007. The essence if it was that not all complexity comes from necessity. Sometimes it just comes from “cleverness”: ”code by über-programmers is often based on speculative generality and gratuitous use of advanced techniques and language features”.

J2EE and Spring

A great example of removing complexity is Spring. Rod Johnson identified a problem: J2EE projects are often over-engineered, and J2EE with EJB is a heavyweight framework with lots of complexity. In his book “J2EE development without EJB” he simply states: “There are simple problems”. Not saying every problem is simple, but the problem with J2EE was basically that it said that all problems where complex. His solution was to remove complexity and over-engineering, and from that emerged Spring. No need to say that Spring is the prefered framework for web development on the Java platform today.

- Tore Vestues