Schauderhaft

You should Provide a Service, not a Defense

Published at: 07:03 am - Sunday March 07 2010

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.

Posted in: The Rest, Uncategorized by Jens Schauder No Comments service

Careers for Developers

Published at: 11:02 pm - Sunday February 28 2010

Many developers try to get into (project)management. That is ok I guess. But what bothers me is, that many developers do that without actually wanting to be managers. It’s just that they want to make some progress and the only career option available is to get into management and manage larger and larger teams, or leave the company to work somewhere else.

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.

Posted in: Management, Uncategorized by Jens Schauder 2 Comments career, developer

Blogs and Twitter Accounts of 14 Authors of the Agile Manifesto

Published at: 10:02 pm - Sunday February 21 2010

When diving into the world of blogs and twitter it can be confusing to get started. Which blog should you read? Whom to follow on twitter? When you are in software development I have an idea for you. Why don’t you check out the authors of the agile manifesto? Here they are with their blogs and their twitter accounts:

Kent Beck: blog twitter

Alistair Cockburn: blog twitter

Ward Cunningham: couldn’t find a blog; twitter

Martin Fowler: blog twitter

James Grenning: blog twitter

Jim Highsmith: blog twitter

Andrew Hunt: blog twitter

Ron Jeffries: blog twitter

Jon Kern: blog twitter

Brian Marick: blog twitter

Robert C. Martin: blog twitter

Ken Schwaber: couldn’t find a blog; twitter

Jeff Sutherland: blog twitter

Dave Thomas: blog twitter

Authors I couldn’t find blog nor twitter account of:

Mike Beedle (there is a twitter account on that name, but it has no sign other then the name to belong to the person we are looking for), Arie van Bennekum, Steve Mellor

If you are interested in following these people you might interested in the little list of them I created on twitter.

Posted in: The Rest by Jens Schauder 4 Comments agile manifesto, blog, twitter

Why SQL Sucks

Published at: 12:02 am - Monday February 15 2010

About two weeks ago at work we discussed different strategies on testing databases. Although there are ways to do it, they are all more or less painful. And finally we all parted in agreeing: (SQL) databases suck, SQL sucks and testing databases and SQL sucks as well. We are only testing this crap because the only thing worse then database tests are untested databases. But complaining doesn’t help. I have heard you are supposed to ask 5 times “why?” when faced with a problem. Maybe it was 7 times? Don’t know lets start with asking it once:

Why does SQL suck?

Hard to parse for computers: I don’t know much about parsing, but it seems to be hard for a computer to identify the bits and pieces of a SQL statement, when it is not really SQL but just almost SQL. This results in really crappy IDE support, because the editor doesn’t know what you are trying to write, before you finished it.

Hard to parse for humans: One of the ideas behind the design of SQL was to make it look almost like a sentence. While this works for trivial statements, it completely falls a part when you have some serious statement at hand. For an extremely bad example check out the turing engine implemented in Oracle SQL. Side Note: aren’t some fluent APIs trying to do just that.

Not consistent:Why does the having clause exist? Why nothing similar for group by? Who came up with the syntax of analytic functions. Why can I reference an expression defined the column list in the where clause, but not in the group by clause?

(Almost) no modularization: You need this real complex where condition in another select? Copy it. You need to join the same bunch of table, just with a tiny change in one condition? Copy it. You want to use the same group by clause in a different select? Copy it. There are few little things you can do to break your SQL code, but it is nothing compared to the power of a modern language like … e.g. … Fortran 66.

No decent development environment appart from the target environment When you write a java application (and you do it the way it is supposed to be done), most of it can get compiled, and executed in a simple JVM. No web server needed, nor application server. Compare that to SQL. The only thing that can properly compile and execute a SQL statement is a database. And not just any database, but a database with all the accessed tables created and filled with data. This does not help when writing SQL code.

Ok, we have some reasons for SQL sucking so badly. What’s next. How about asking “Why?” again?

Why are all these things true about SQL?

That answer is easy: I have no idea. So let’s step right ahead and ask again “Why”

Why does a curious developer with over 10 years of experience in database development know some reasons why SQL sucks, but can’t answer the simple question, why these reasons apply?

I think it is because nobody really discusses SQL (at least not loud enough for me to hear). I know there is the No-SQL-Movement, but I happen to think that a relational database is a pretty decent solution to many things. There are also things like the Hibernate Criteria API and HQL. But those do not operate on database schemas, but on classes and objects. While this is fine when you wan’t to work with classes and objects, it sucks when you just want to process large tables. When processiong 100K database records pulling each out of the database, instanciate an object, manipulating it and writing it back is not an option.

Yet a way to write queries in a more modular, easy to parse and easy to test way would be highly appreciated.

Posted in: Softwaredevelopment by Jens Schauder 11 Comments sql

More on JUnit Theories

Published at: 03:02 pm - Sunday February 07 2010

In my last blog post, I described how to use JUnit Theories to create large amounts of test runs, with very limited amount of work, like so:

import static org.junit.Assume.assumeTrue;

@RunWith(Theories.class)
public class TheorieTest {
@DataPoint
public static String a = "a";
@DataPoint
public static String b = "bb";
@DataPoint
public static String c = "ccc";
@Theory
public void stringTest(String x, String y) {
assumeTrue(x.length() > 1);
System.out.println(x + " " + y);
}
}

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):

@RunWith(Theories.class)
public class TheorieTest {
@DataPoints
public static String[] a = { "a", "bb", "ccc" };
@DataPoints
public static Integer[] j = { 1, 2, 3 };
@Theory
public void someTest(String x, Integer y) {
assumeTrue(x.length() > 1);
System.out.println(x + " " + y);
}
}

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):

@Retention(RetentionPolicy.RUNTIME)
@ParametersSuppliedBy(CreditCardSupplier.class)
public @interface AllCreditCards {}
//—————————————————————–
@Retention(RetentionPolicy.RUNTIME)
@ParametersSuppliedBy(NameSupplier.class)
public @interface AllNames {}
//—————————————————————–
public class CreditCardSupplier extends ParameterSupplier {
@Override
public List<PotentialAssignment> getValueSources(
ParameterSignature signature) {
ArrayList<PotentialAssignment> result = new ArrayList<PotentialAssignment>();
result.add(PotentialAssignment.forValue("Amex", "Amex"));
result.add(PotentialAssignment.forValue("Master", "Master"));
result.add(PotentialAssignment.forValue("Visa", "Visa"));
return result;
}
}
//—————————————————————–
public class NameSupplier extends ParameterSupplier {
@Override
public List<PotentialAssignment> getValueSources(
ParameterSignature signature) {
AllNames annotation = signature.getAnnotation(AllNames.class);
System.out.println("just wanted to show that I can access it "
+ annotation);
ArrayList<PotentialAssignment> result = new ArrayList<PotentialAssignment>();
result.add(PotentialAssignment.forValue("Alf", "Alf"));
result.add(PotentialAssignment.forValue("Willie", "Willie"));
result.add(PotentialAssignment.forValue("Tanner", "Tanner"));
result.add(PotentialAssignment.forValue("Cat", "Cat"));
return result;
}
}
//—————————————————————–
@RunWith(Theories.class)
public class SuppliedByTest {
@Theory
public void imagineThisIsATest(@AllCreditCards String x, @AllNames String y) {
System.out.println("consider " + x + " / " + y + " tested.");
}
@Theory
public void testIntegers(@TestedOn(ints = { 2, 3, 4, 7, 13, 23, 42 }) int i) {
System.out.println(i);
}
}

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.

Posted in: Softwaredevelopment, Uncategorized by Jens Schauder 6 Comments Java, testing, theory

New Feature of JUnit: Theories

Published at: 10:01 pm - Sunday January 31 2010

A couple of months ago I blogged about JUnit Rules, one of the new features in JUnit. While fooling around with JUnit Rules, I found a couple more features that you might be interested in. So here it comes: Theories! It turns out Theories are really a piece of cake. Try this:

import static org.junit.Assume.assumeTrue;

import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;
@RunWith(Theories.class)
public class TheorieTest {
@DataPoint
public static String a = "a";
@DataPoint
public static String b = "bb";
@DataPoint
public static String c = "ccc";
@Theory
public void stringTest(String x, String y) {
assumeTrue(x.length() > 1);
System.out.println(x + " " + y);
}
}

When you run this you’ll get this as an output (and one successfull test):

bb a
bb bb
bb ccc
ccc a
ccc bb
ccc ccc

So what is going on? The first thing to note is that this test is executed by a specialized runner of type Theories. This runner executes all the public methods annotated with @Theory. Differently from normal tests theories have parameters. In order to fill these parameters with values, the Theories runner uses all the public fields of matching Type and annotated with @DataPoint. When you take a look at the output, it should be obvious why this is more powerful then parameterized Tests: Every combination of values is tried, thus with e.g. 4 parameters with 4 distinct values each, you end up with 256 test runs.

The idea is to specify a theory about the object under test, that holds for a large class of states and parameters. Then you provide those as parameters to the test method which will test the theory.

A probably very common case is that a theory is known not to be valid for certain cases. You can exclude these from a test using the Assume class. If an assumption doesn’t hold, the test is silently ignored. This is used in the example above to prevent ‘a’ to be used as a first parameter.

There are some more tweaks to Theories in JUnit, which I will cover in a later blog. Until then enjoy the new feature. But keep in mind the package in which theories reside up to now: org.junit.experimental.theories so I’d expect some changes in the API and at least a change in package name.

Posted in: Softwaredevelopment by Jens Schauder 3 Comments junit, testing, theory

Mixins, Inheritance and Delegation

Published at: 01:01 pm - Sunday January 24 2010

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.

import java.beans.PropertyChangeSupport;

public class PropertySupport {
protected PropertyChangeSupport propSup;
}
public class UserEntity extends PropertySupport {
private String firstName;
public void setFirstName(String aFirstName) {
String oldValue = firstName;
firstName = aFirstName;
propSup.firePropertyChange("firstName", oldValue, firstName);
}
}

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:

public class Cat implements Furry, FourLegged {

FurryDelegate fd;
FourLeggedDelegate fld;
@Override
public void pet() {
fd.pet();
}
@Override
public void runFast() {
fld.runFast();
}
}

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

class Animal

class Cat extends Animal with Furry with FourLegs{
}
trait Furry{
def pet() {
println("purrrrr")
}
}
trait FourLegs{
def runFast() {
println("I'm gone")
}
}

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:

class Superclass

class Mixin extends Superclass with Trait {
// … more stuff goes here
}
trait Trait {
val delegate = new TraitImpl // this should be some kind of DI or lookup in a real system
def aMethod() {
delegate.aMethod()
}
}
class TraitImpl extends Trait {
override def aMethod(){
println("you just called me")
}
}

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.

Posted in: Softwaredevelopment, Uncategorized by Jens Schauder No Comments delegate, inheritance, Java, mixin, scala, trait

8 Reasons why the Estimates are too low

Published at: 02:01 pm - Sunday January 17 2010

Hourglass

One of the most difficult tasks in a software development project is estimating the size of the project. Unfortunatly very often you have to do it at the very beginning of a project, when you have the least information. The result at the end is very often a large difference between the original estimate and the actual time and money needed.

If the difference is positive as often as it is negative this is kind of OK. But in some teams estimates are too low almost all the time! The obvious strategy often employed is to add a certain percentage to the estimate. But of course that is just fixing the symptoms, because most of the time nobody knows the reason. So in this article I am going to show a couple of possible reasons for bad estimates, how to identify these and also a possible fix.

These are the kinds of reasons I identified so far:

Super Hero Estimates: Often estimates are done by a very experienced developer (Super Hero). When they estimate a task they imagine themselves doing it. But while the esimate might be correct for the Super Hero in the project more average developers work on the task. And since they aren’t Super Heros they need longer.

You can identify this kind of situation by letting different people do the estimates. Including average developers. If the estimate of the Super Hero is constantly below that of the others, the fix becomes obvious: Use the estimate of the other developers. Don’t exclude the Super Hero from estimating though. Experienced developers a good at identifying things others tend to forget.

Wrong Team: This one is similar to the Super Hero Estimate, in that the estimate is correct for a team of good (possibly excellent) developers. It differs though, because in this scenario, this is the actual team that should do the project. But for one reason or the other the project gets staffed with a different team. Maybe developers that aren’t that good. Or maybe just a team that doesn’t no the domain, the framework or the programming language that well.

In order to identify this situation, talk to the people doing the estimates. Let them specifiy the assumption they had in mind when they made the estimate, and compare it to what actually happend in the project.

If this is actually the problem you have two choices: The first is: stop switching teams. This doesn’t work most of the time, since you don’t switch them just for fun, right? So you are stuck with the second option: Even when you plan to use your top team, make the estimates on the assumption that an average team will do the job. Be honest to yourself about what an average team is.

Guessing in the dark: Often the information available about the project at hand is just not sufficient for a reliable estimate. There is only a vague description available.

In order to identify this as the underlying problem, break the project down into tasks, which you estimate. For each task put down the assumptions you are making: what technology are you using, how complex is the logic to implement. During the project check if your assumptions hold or if there are a lot of changes. This is also most of the solution to the problem. Make the description of your assumption part of your estimate. If the assumptions are wrong, the customer may correct those, resulting in a new more reliable estimate. I he changes his mind later on, you have a clean basis for a change management process, which ensures, that changes are possible, but that the one requesting the change is also paying for it.

Forgetting stuff: This one looks very similiar to the previous. Stuff doesn’t get included in the estimate. But this time it’s not because the people doing the estimate don’t know about it, but because they forget about it.

Using the same strategy as for Guessing in the dark should make this kind of mistake obvious. As a remidy, let multiple people do estimates, and compare the results. You should do this based on the broken down tasks, so missing tasks in the different estimates become obvious.

Ball of Mud Projects: When projects base on a specific code base take too long each and every time, a reason might be that tasks keep getting more complex then anticipated. A typical reason for that would be an overly complex and convoluted code base, where nobody really can predict the effects a given code change may have.

In such a project I’d expect a lot 80% syndrome, few test and many swearing developers. Do a code analysis of the code base, with a concentration on architecture and dependency management. If you find a lot of crap, there is just one solution: Clean it up and pay your technical debt. I.e. invest time and money to improve the architecture. I also recommend implementing tests, that prevent the architecture from starting to rot again.

Multitasking: People are bad at multi tasking. So you can’t put your top developer for 20% in five different projects and expect her to work just as efficient as normal. Once you start thinking about it, it should be really obvious if you have the problem or not. And the same should be true for the solution.

Mythical Man Month: Conceptional very similar is the Mythical Man Month effect. Check if your estimates get processed like this: “Frank says he would need 6 months. We need to get done within 1 month, so let’s put 6 developers in the project.” If this is the case you are missing on all the overhead that a bigger team causes. In order to get a handle on that kind of problem read the book Mythical Man Month. I do think that book is overrated, but the chapter about the actual mythical man month is right to the point.

This problem is almost guaranteed to hit you when you do a project that is a magnitude larger then your normal project. You will underestimate by a large amount, if you do not factor in the exponential behaviour of communication over head.

Lazy Developer: Of course there is always the possibility that the developers just aren’t working hard enough. In my experience, most of the time, this isn’t a problem. But I guess is it does happen. Symptoms could be lots of open browser tabs, on sites that have no relation to the work at hand, acompanied by hectic wiondow/tab switching, when the boss drops by. If this is a problem with one developer, it might be that the developer has the power to change it. But if many developers spend their time procrastinating it is most probably a management problem. Procrastination is not fun. Getting stuff done is. So if everybody is procrastinating something in the environment is probably highly demotivating. Find out what it is and get it out of the way.

Posted in: Management by Jens Schauder 11 Comments estimate, project management, software development

New Project’s Resolution

Published at: 12:01 pm - Sunday January 10 2010

Fireworks

In a couple of days I’ll start working on a new project. Actually it is an project that I worked one or two years ago. I think I did decent job last time. But there is always lots of room for improvement. So today I want to list a couple of things I want to do bettern than the last time.

More Tests – When working on that project I was the only person with real experience in automated testing. I am proud that we had a test suite and that this test suite still exists and put to good use and actually grew during the last months. Yet I consider the coverage of the tests not sufficient by far. So for every code I write, I will add an extensive set of test. I’ll also add tests for existing code, when refactoring.

Earlier Tests – One reason we didn’t produce as many tests as I would wish today is that we didn’t do TDD. It probably was a correct decission the last time, since it would have been just to much. But this time I will practice TDD as good as I can.

Cleaner Code – One of the first tests I wrote back then was a test to ensure that we don’t have circular dependencies. We succeeded in this, but still parts of the system a pretty tangled. We gonna improve that. Appart from the knowledge I took from Clean Code I’ll plan to use the toxicity metric as an important tool for that.

Dependency Injection – We considered using Spring and decided against it, because we already had about 20 libraries we hardly knew in the project. Again at that time it was a reasonable decision. But in the meantime I learned what we could have gained by using Spring. I’ll propose using it, but even when the team declines again, I’ll be able to use the concept in order to improve the code base.

So these are the things I want to improve on in the next project. What are the things you want to improve on in your next project?

Posted in: Softwaredevelopment by Jens Schauder 1 Comment clean code, dependency injection, resolution, testing, toxicity

Is ISO 9001 obsolete?

Published at: 06:01 am - Sunday January 03 2010

Rusty Car

I just finished ‘Here Comes Everybody’, a must-read for anybody trying to understand what is going on with all this social media stuff. One point Clay Shirky makes, is that the various web2.0 tools make failing cheap.

If in the 80s you had an idea for a group to form, you had a lot of things to do, many of which cost money: Finding a room to meet, printing fliers or ads to promote your idea and so on. If your idea failed, all that money was wasted.

Compare that to the situation today. Create a webpage, and promote it using facebook, twitter, xing or many of the other tools is free. All you have to invest is your own time. If it fails, nothing is lost. Actually something that fails today might get picked up tomorrow by somebody else and brought to success. Like a wikipedia article which is a stub at first, but then evolves in a well written article, through many mostly small changes an improvements. If one of the changes is bad, again the cost of this is minimal. Somebody will notice it and revert the change. Cost: a couple minutes of online time for bad article and 5 minutes work. Compare that to a typo in a printed encyclopedia. Fixing a typo would cost thousands of euros. So it won’t get fixed until the next revision which might take years to come.

So where is the relationship to the title of this post, namely the ISO 9001? One of the corner stones of modern quality management is to prevent errors to happen. This is a good thing under the assumption that fixing errors is way more expensive then preventing them. For building a car, this is probably still true: “Oh the brakes didn’t work? Probably because we installed any in the first place. Let me fix that right away. What do you mean, you don’t want them anymore? Oh you are dead … I see.” But for building software, for creating documentation for the software, for gathering requirements of the software, this assumption is wrong in many cases.

I am trying to write clean code, tested code, working code all the time and I expect my coworkers to do the same. But that doesn’t prevent me from checking in less then perfect code into the version control system. Because as soon as it available for others to see and to use, they might find bugs, or even fix some. They might provide feed back for improvement or further development of the piece. I would not accept a rule that disallows less then perfect code (or documentation) to be seen by others.

So, is ISO 9001 obsolete? I’d say NO for the following reasons:

While it is OK to have broken stuff around, it is not OK to leave it that way. An implementation of ISO 9001 may help with making this clear for everybody.
The agile / social media way of doing things does lead some people to the impression that it is OK to write crappy software. Although it is hard to understand how they come to that conclusion when reading the agile manifesto or any of the well known literature on agile software development, it still happens. Fixed rules inside a company of what must be done before releasing software or any development artifact to a customer.
While the ISO 9001 is build on the idea of preventing errors it actually isn’t hard coded in a form that requires anything like a Waterfall approach.
Even in a software developing company there are processes that need attention and that don’t need, and maybe shouldn’t be as flexible as a wiki page (consider the processes of paying the salaries with correct taxes and all)

But there are a couple of things that pop up around ISO 9001: Lengthy specifications and lengthy review processes of that specification. Many companies like to create those, and many people seem to think they are a requirement of the ISO 9001. This is not true. The norm requires that you know what you need, before you build it. A specification of the complete system certainly fits that requirement. But since you don’t create a complete new CRM in an afternoon, you don’t need the complete specification.

If you agree with a customer on a couple of user stories to be implemented in the next two weeks, and write those down on a whiteboard or in a webbased application or on some sheets of paper, any auditor of ISO 9001 conformance will have a problem criticizing that. If you use a whiteboard, you might want to make a photo of that. And if you write it down as a Fitnesse test, the auditor will probably be impressed.

So no, ISO 9001 is not obsolete. What is obsolete are ways of implementing the ISO 9001 that are damaging the reputation of that norm.

Posted in: Quality Management by Jens Schauder 2 Comments ISO9001, quality