10 Reasons why creating a program takes longer than it should

June 27, 2007, No Comments

The following is a list of annoying timewasters that I seem to stumble on over and over again… Bigger projects face more of these potential timewasters, making estimates more inaccurate.

10 - Coding Style Issues: I’ve had discussions about where to place {, whether it is better to have long lines on 1 line (and use the scrollbar) or on several lines. About prefixes for variables. The list goes on and on. The fun part about the discussion is: Nobody listens to your arguments, because it’s all about personal preference. Why can’t we just all agree on my style?

Tools like Checkstyle seem to magnify the problem rather than make it disappear.

9 - MS Word - An extremly poor tool to communicate requirements.

8 - Deploying: How much time should be between successfully testing a feature on the developers machine and getting that feature on a server for everyone to try out? In some places, the real work just begins at that point…

7 - Mapping Data, Data migration: Whenever you get in touch with data that needs to be moved from one system to another, you’re basically doomed. Services (of the SOA kind) can be just as painful. There is so much “data mapping” going on in Enterprise environments that I think it would make sense to find a new Job Title for the ‘Datamapper’.

6 - Strange Server Behaviour: Things that should just work, don’t. Of course, sometimes they do. The problem usually lies in your code - well, that doesn’t make it easier, because you think the problem lies somewhere else. For example: This is wrong. So wrong.

5 - classpath/dll mess: I don’t remember how long it took to find out exactly which dll made Crystal Reports crash. But it wasn’t fun to find out and it was more than a day. The same applies to “commonly used java jar files”, which are copied all over your system - often in different versions. It’s almost guaranteed you have the wrong one in your classpath.

4 - Useless Errormessages: Try integrating MS Office. No matter what you do, if something goes wrong a very helpful message appears. Like ‘Error’. Or my alltime favorite from the Jet Engine: “Reserved Error - There is no message for this error.”. Nothing beats a little humor in your daily life - especially when the deadline is close…

3 - Defects (aka bugs): Creating a feature is sometimes rather trivial. So is it justified to spend 1 h to write unit tests for a feature you can implement in 5 minutes? Well, you can always skip it and then spend 3 h testing and 3 h debugging next week, when sombody else broke your feature. Good thing the fix only takes 5 minutes (never mind that an other feature might be broke by the “fix”).

2 - Communicating with other systems/programs/services: It all looks nice and harmless. Always. OK - You have to map data, which can be a problem (see point 7).

If something doesn’t go right (and it never does) you sit there with no possibility to find out why - because you don’t have access to the logs of the other system. If you’re lucky you get an error (See point 4). Sometimes you’re not lucky and you just sit there and the stupid thing doesn’t do anything.

And don’t even get me started on Character Set Encodings. Retrieving data from an other system: 1 h. Figuring out why you get a ‘?’ instead of an ‘€’ sign: rest of the week.

1 - Bad Frameworks: First you spend time learning what the framework can do. Then you start doing a project and learn what it can’t do. Then you spend several hours trying to do something that should be trivial, just because the framework prevents you from doing it the trivial way.

Honorable mention goes to:

11 - Missing methods/Overdesigned classes: Give me one good reason why this


cal = new GregorianCalendar(2006, 1, 31);


creates an instance of the calendar set to the 3rd of March 2006.

And as a bonus

12 - Getting the GUI exactly right. Most of the things look and behave just like you’d like. But the few things that don’t, take forever until they do.

[UPDATE]:

13 - Reports: You can spend so much time on creating nice reports. To make things even more fun: The reports are usually some of the most important things to come out of the system, because they will often be sent to the customers. Therefore they have to be perfect. Oh. And usually work on the reports starts after everything is finished. So time is limited.

Testing unclear requirements

June 10, 2007, No Comments

In Lukas’ talk there he pointed out a bad requirement, that would be impossible to test because it lacks details:

The instrument shall provide the capability for authorized users to create, edit and load files.

What do you do about a requirement that is vague?

One way is to raise your hand and tell people that this requirement isn’t testable. It needs more detail. Have them write it down in a document.

Another one is to just write test cases for it. Like this:


Try to login as Administrator and create a tst file.

| enter | username | admin |
| enter | password | geheim |
| press | login |
| check | isInRole | Administrator |
| check | countFiles | 0 |
| enter | createFile | newTestFile.tst |
| check | countFiles | 1 |
This is an almost-valid fitnesse test, that tries to login, makes sure the person is in the administrator role and tries to create a file. Similar ones are needed for somebody who doesn’t have access rights. For editing and loading.

The requirement quickly becomes less important, because the details are in the tests. The tests have to be in an easily readable format. By readable I mean:

The customer (a nontechnical person) has to be able to look at it and say whether this is what he wants or not. If he doesn’t like it, he should be able to change it or enhance it.

To further limit possible test tools, add to the above:

It has to be possible to specify the tests before any software exists.

And:

It should be little or no effort for the programmers to connect production code to the test specification.

Is there a tool that allows for all that? I don’t know. I guess fitnesse comes closest. But there is a lot of room there…

As you can see, the requirements can be vague. But with the details documented in automated test cases you are in a much better shape than with a BLOB called requirements document.

Another question is: Do you really need to write down those details at the beginning of the project?

Create Quality

June 7, 2007, No Comments

Recently I was at an event from the company I worked for. The topic of the event was: “Creat Quality”

Creating quality is something that is very much at the core of agile development processes and as a programmer is very important to me. My expectations were very high.

After the event I was disappointed. The talks were filled with waterfall-centered thoughts and how a testmanager can help create quality in that environment.

But as long as you think in waterfall, testing will always come after implementation and way after design. And I mean that in every possible way:

Testers opinion count less
Testers (often) get paid less
Generally, testers are less important because they “only use the software and report bugs”

No amount of reviews, checklists, metrics will change that. What you have to change is the way software is created. Where the tester, the programmer, the project manager and the customer representativ/analyst/product manager are all equals.

You can’t reach this in a waterfall, because by definition these roles don’t work together - they work after each other. You can try to circumvent waterfall by including the testmanager early - but he’ll always be “out of his phase”. This means, he’ll be tolerated and if he steps too far, the “phase owner” (*) won’t be happy.

I was very surprised that agile methods didn’t find more friends among Testers (at least the ones I know). But I think I understand now:

If your company really wants to create quality software, it doesn’t need more testers.

What agile methods promise seems to somehow make the testers job disappear. There is no testing phase, so where are the testers? How should it be possible to develop software with few defects without a test phase?

Yes. Agile Methods kill the test phase. But it needs testers and it requires them from day 1. Automated tests are important in XP and in many other agile methods. Customers and programmers mostly think about the “happy path”. Somebody has to help them think of missing tests. Somebody has to help them think of ways to test complicated things automatically. Somebody has to let them know that the software created in the last iteration wasn’t up to the quality standards the team wants to deliver. Act on that information and help fix the problem.

---

(*) I use “phase owner” as the person who has to say how one phase is run. This may be the Senior Designer for the Design Phase or a Chief Programmer for implementation. Whoever, don’t go to their office and try to tell them how to run the show.