About Johannes Brodwall

Johannes is the chief scientist of the software offshore company Exilesoft. He's got close to 15 years programming Java, C# and a long time ago other languages as well. He believes that programming is about more than just writing the code, but that too many people lose touch with the coding as well. He has been organizing software development activities in Oslo for many years. In addition, he often speaks at conferences all over Europe.

Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.

Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?

Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.

Developer: That should be doable.

They work out a few more details and get on their way. Total time, 30 minutes

The low ambition implementation

Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.

Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.

Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).

Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.

Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.

Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?

Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.

Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.

Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.

Developer: (sigh) I guess it can’t be helped. We’re on it.

Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.

The quick completion

Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.

Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.

Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!

The contrast

Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.

When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.

When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.

On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Recent Jobs

No job listings found.

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.