“Planning is the death of any project” http://bit.ly/bFYkAW Just an entertainment story, but fun nonetheless

I’m certainly proud to produce something that is considered fun. Yet my little story actually has some serious background. Of course the simple task of making coffee doesn’t justify elaborate project planning. But which task does? As we have seen, simple tasks don’t.

So how about complex tasks? Tasks that depend on circumstances in many ways, like e.g. balancing a stick on a finger, or playing table tennis. It would surely simplify the task, if we knew exactly when to make which movement. But we can’t plan this kind of thing, because the tiniest deviation from the intendend movement at some point in time will greatly change the required action some time later.

The coach teaching me project management had a great example of a project needing very accurate planning: When you build a nuclear reactor, the core will get encapsulated in a huge steel chamber. There are only very few cranes huge enough to move this thing. And they need a rail track to get to the building site, as well as a foundation for the crane to stand on. Rent of this crane is expensive as hell and you have to fix the dates years in advance. Everything that was needed for this crane and the needed structure, was planned with great care, to make sure everything was in place.

Few of us build nuclear reactors. For all others check these rules as a guide for the amount of planning justified:

• How plannable is it anyway? Don’t try to plan the unplannable. Get it out of the way instead. This is what many agile approaches do, when they implement the most risky stuff first.
• Do you have fixed dependencies between tasks? A plan becomes more helpfull, when you have many dependencies between tasks, possible with long ramp up or preperation time. As with the crane: The task of moving the steel shell wasn’t  very long, but the preperation had to start years ahead. Without a plan it gets easy to kill a deadline long before it comes into sight.
• What is the damage done, when you don’t stick to the plan. In some projects, the only damage done is that somebody has to adjust all the plans. In that case, you might just as well scrap the plan.

Cannon

Let’s assume you are manager (or just part of) a small department. The task of the department is to make sure that everybody in the company is using Grglwup for wumpeling and does so in the correct way. What do you do to achieve that?

The approach I see most of the times lets me wonder, if companies are run by Vogons. It looks like this.

A document is written describing the process for wumpeling by use of Grglwup in great detail. It gets published on a newly created website, which nobody knows about.

A 23 step process is put up defining how to get Grglwup, how to get a license for it and who is allowed to use it. It describes the 5 forms 7 signatures and 3 trainings you need, but it lacks any reason, why it is a good idea to us Grglwup instead of Open G which you could download and use for free and which is so easy to use, that anybody will be done with the task of wumpeling within 5 minutes.

Of course nobody adheres to that process. So an evaluation if wumpeling is needed and a 5 day consulting with the fixed result of advising to use Grglwup are made a required and expensive part of every project.

That was easy right? Now nobody can do any wumpeling without Grglwup as desired. At a side effect your department grew by a factor of 5 in order to handle all the consulting. Oh, and the cost of every project increased by about 10.000Euro for the consulting and getting through the whole process. Therefore people will hate you and your department.

I propose a different approach.

Find out why Grglwup must be used. If it is a valid reason, make sure everybody at least in your department understands it. If there aren’t valid reasons, fight the requirement.

Everything else is about making work with Grglwup a pleasure:

Write easy to use and fun to read documentation for it. Prefer a wiki as a platform so everybody can improve on it.

Make sure that that page shows up whenever anybody is searching for Grglwup, wumpeling or Open G on your intranet.

Offer free training for use of Grglwup.

Make the question: “What else can we do to make working with Grglwup easier?” part of every contact with a user.

Make sure that you reply to those that answer the question. Actually reply twice: First to confirm that you received the answer and then when you actually provide something.

You probably would like to have a single way uses address your team with questions about Grglwup. Still you should accept any way of communication: e-Mail, fax, phone or whatever. Don’t make them use your preferred tool. Of course you are free to funnel communication inside your department into a single tool.

Make sure everybody who might need to do some wumpeling, knows about you and your department.

If you succeed in this, everybody use Grglwup because it is the easy, the obvious thing to do.

Of course all this will cost money, just as the first approach. But you can’t charge the users for that. They aren’t the ones that want to use Grglwup. The company wants. So the company should pay for it.

I can only speculate why this is so. Maybe managers can’t think of alternative career paths? Well, I think I can help with that. Here are a couple of things developers might consider a step up on the career ladder.

Trainer: Many of the better developers I know, love to teach their knowledge to others.

Mentor: While a trainer will do workshops, a mentor will work together with a single coworker, or a small group, to pass on his knowledge. It is a lot of work, a lot of responsibility but very satisfying when the student comes back to the mentor after sometimes with something like “I learned a lot in the time with you as my mentor.”

Firefighter: Send a fire fighter into projects which have problems. The firefighter moves in, puts out the fire and moves one to the next project/fire. It makes a job extremely interesting but also stressful.

Technical Teamlead / Software Designer / Architect: Whatever these people get called at your place, they have a larger than average saying on what tools, what technologies get used and how.

Researcher: The guy evaluating the new languages, the new tools before anybody else gets to use them.

Prophet: While the researcher evaluates what can be done today, the prophet tries to see in the future, evaluates all the hip stuff in order to separate the hype from the good stuff.

Don’t get me wrong, nobody should print business cards with these titles on. But managers should make sure the developers who should do these things know about it, get the appropriate resources. And they should make sure that these tasks a only put in the hand of the best people.

The trick is simple to provide data points for every parameter type of the test method. The JUnit Theories Runner will call the test method with every possible combination of datapoints. If you think a little about it you will soon realize some of the limitations of this approach:

• You’ll soon end up with lots of data point fields cluttering your code
• Parameters of the same type will receive the same set of parameters, even when the usable range of inputs is completely different.

Fortunately the developers of JUnit provided really nice solutions to these problems.

Instead of specifying single data points, you can provide a full array of datapoints using the @Datapoints annotation, like so (add imports for good measure):

This of course is much less verbose. Instead of an array you may provide a method returning an array, or at least it looks like this should be possible. But when I tried it JUnit seemed unable to handle the types correctly resulting in IllegalArgumentExceptions. Guess I’ll have to file a bug when finished with this article …

But we still need to take care of parameters which have the same type, but very different meaning and therefore different useful values. The clean OO way of doing things would be to get rid of the generic types like String and use stronger types like CreditCardNumber or Name instead. But then in a perfect world we wouldn’t need tests, because our programs wouldn’t contain any bugs to begin with. So lets try this instead (Again imports omitted):

Wow, thats a lot of code. Just look at the last piece and see what appears in the console when we run it:

just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Amex / Alf tested.
consider Amex / Willie tested.
consider Amex / Tanner tested.
consider Amex / Cat tested.
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Master / Alf tested.
consider Master / Willie tested.
consider Master / Tanner tested.
consider Master / Cat tested.
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Visa / Alf tested.
consider Visa / Willie tested.
consider Visa / Tanner tested.
consider Visa / Cat tested.
2
3
4
7
13
23
42

Have a look at the row beginning with: “consider”. Obviously the Theory imagineThisIsATest gets fed with the values from the CreditCardSupplier and NameSupplier. The parameters and the ‘Suppliers’ are connected by the two annotations @AllNames and AllCreditCards. So whenever you have a parameter to a theory where the type alone is not sufficient for identifying the kind of values that should get used, you can simple create an annotation, which itself is annotated with a reference to a ParameterSupplier class and you are all set. You might think this is a lot of code for supplying a handful of parameters. You are right, but remember, that you can reuse your suppliers wherever you need names or credit card values in your tests.

Now let’s look at the first line of the output:
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
It simply shows of that you get access to the annotation (and actually the signature of the compete test method. This can be very useful, when you want your supplier to behave differently for different theories. Have a look at the NameSupplier above to see how this works.

JUnit actually comes with an example where this is used, and I demonstrated it with the other theory in the demonstration code above. The @TestedOn annotation takes an array of values to be used as data points for the annotated parameter.

Thats it for today. I hope the power of theories became obvious, as well as the power you have as a developer to extend that mechanism. Again be warned: All this nice stuff is in a package named experimental for good reason. If you use it, you might find bugs, and thing will likely change at least in name in an upcoming version. Taking about versions, I am using junit4.8.1 for the examples.

For next week the conclusion of the little series about JUnit theories is planned, with a few thoughts on use and danger of this kind of testing.

Blender

A week ago I started learning Scala. One of the features I found pretty interesting are mixins and traits. That was just the point of time, when I read this little tweet of GeekyL:

“i am still not sure if mixins are super cool or dark magic.”

Of course I was instantly reminded of the time when the dinosaurs dominated the world and I was learning the first little bits of OO and C++. I thought inheritance and polymorphism was great and the solution for every possible programming problem there is. It turned out that was not the case. Actually inheritance can result in pretty ugly code.

So GeekyL’s tweet got me thinking: Do mixins have the same problem? What exactly are the problems with inheritance anyway? Time for a new blog post.

What are the problems of inheritance?

Inheritance for code reuse: It is tempting to have a class inherit from a superclass just because the superclass has some useful feature. Like this.

The problem with such code is that inheritance suggests a is-a-relationship, which in this case is just wrong. A UserEntity is not a PropertySupport, it just uses one.

Multiple inheritance: At least in java a class can only inherit from one superclass. But many classes are many things. For example, a Cat is a Carnivor, it is a FourLeggedAnimal and a FurryAnimal. Without multiple inheritance there is just no way how to model this with class inheritance. With multple inheritance you can extend all these classes at the same time, but now you inherit the top class Animal three times, which at least is ugly.

So the proper way to do this kind of stuff in java is to use delegation and interfaces:

Which works in the sense that you can pretty much express the kind of things you need to do, and which you might be tempted to solve with class inheritance. Of course the draw back is that you’ll have to create all theses trivial delegate methods.

In Scala you have the option to use Traits. Like so

Obviously this contains much less code duplication then the java version. Does it have drawbacks? You bet.

Mixins are firmly tied to the traits they use. Imagine a more complex trait, which itself uses many other clases and resources. Once you mix in such a trait you have a strong dependency. Therefor I suggest the following pattern for getting the reduction of code duplication from traits and the flexibility of delegates: Use Traits, which don’t have a real implementation, but use a delegate for doing all the real stuff, this way you can switch the implementation with touching just a single place:

Summary: Traits can be used to solve some of the problems of inheritance, but they might introduce strong coupling, which you can easily be avoided.

I published before an OracleNamingStrategy that fixes this problem by creating abbreviations on this blog. But writing a new blog entry with all the code every time I find a little glitch in the code felt just wrong. So I published it as an official Open Source Project over at google code: The Hibernate Naming Strategy for Oracle! And I just released the first version. and since it is so extremely simple, it isn’t even a jar but a single java file.

I’d be glad if this is of some use for other developers. If you like it, drop me a line in the comments. If you find a bug or have an idea for improvement use the issue tracker.

I hereby claim that the chance of your code being beautiful rises when you apply four principles which origin from graphical design. And with beautiful I’m not referring to some pure aesthetic value but the attribute that is considered an important aspect when judging quality especially maintainability of code.

So here are the four principles:

Contrast

In graphical design contrast is often achieved by using different font, size or color. Contrast is used to add emphasis on the really important part of a document or a work of art. But how can we add contrast to source code? For one it is done by our IDE or editor, by setting key words in a bold typeface, using a different color for text literals and so on. If you are ever forced to switch from your preferred IDE or rich editor to a simple tool like notepad you’ll see what you miss.
But even without the magic of an IDE you can and should profit from using contrast in your code. Most coding conventions go into great detail about adding contrast to code. CONSTANTS are all caps. Classes and Interfaces begin with capitals, methods, variables and fields begin with small letters.
Another way to add contrast is with comments. Who hasn’t used a comment like this?


/*********************************
DON’T DO X OR Y WILL HAPPEN
*********************************/


It’s all about contrast and most developers use it pretty reasonably in my experience.
Also if your method spans 50 lines, everything gets lost in the noise. There is just no contrast. The header of a method does add contrast.

Repetition

In graphical design this refers to repeating graphical elements to convey a feeling of cohesion. In software development repetition comes in the form of code conventions. Do your factory classes have the suffix “Factory”? Has the single instance of a singleton always the same name? While I haven’t found a group of more the one developer that could agree on a code convention without discussion, everybody always agreed on the value of code conventions. Of course Repetition should not be an excuse to use cut’n’paste! The DRY principle still applies.

Alignment

Alignment gives a clean structure to a graphical design. And it does the same for source code. Again you can apply it on various levels. It starts on the code convention level on indenting your code following simple rules. It applies on the method level as well. Do you have six nested if statements? The reader will have problems to identify the alignment and to understand your code. Or you can apply it on the package level. Has your package structure about the same depth every where? Or have 90% of your packages no subpackage at all but the remaining 10 percent have a subpackage structure 5 levels deep?

Proximity

The principle of proximity simple means: put those things together that belong together. And once more this can be applied on various levels in software development.
A package, class or method should have exactly one purpose thus putting the stuff need for this purpose inside (close together) and everything else separate. Often you have to prepare two or more objects, before putting them together. In such a case please honor the principle of proximity and put first the code for preparing the first object, then prepare the second object and so on. Don’t mix it together in some random order.
So go ahead write beautiful code.

The original idea of applying these rules to source code comes from a colleague and he told me only briefly about it on a Christmas party. But the details are from my own sick mind, so I am curious if he or any of the readers has some more ideas on applying graphical design principles to source code.

Ein sinnvolles Beispiel für eine Start-Start Beziehung könnte eine Renovierungsaktion liefern. Vorgang A: spachteln der Wände, Vorgang B streichen der Wände. Mit dem Streichen der Wände kann man erst dann beginnen, wenn mit dem spachteln begonnen wurde. Die selben beiden Vorgänge haben auch eine Ende-Ende Beziehung, denn mit dem Streichen der Wände kann ich erst abschließen, wenn sie fertig gespachtelt sind. Zumindest kann also einer spachteln, während jemand anderes (oder der Gleiche mit der anderen Hand) die eben gespachtelte Fläche streicht.

Trotz allem Gemecker, wenn ihr euch mit MS-Project auseinandersetzt, werft ruhig mal einen Blick auf das MS-Project Blog.