Thinking Inside a Bigger Box
Welcome to Johannes Brodwall's blog. I use this space to work on articles mostly about software development, with a focus on Java, SOA, and Agile software development. Many of the articles you will find here are not much more than drafts, and I certainly appreciate input on how to make them better.
If you wonder about the title of this blog, Thinking Outside the Box may answer your questions.
I work as the lead software architect of BBS, the company that handles interbank services in Norway. In my copious free time, I develop software and consult companies in development practices and architecture. For more about the services I can offer, please see my resume.
Submitted by Johannes Brodwal on Sat, 02/14/2009 - 17:57.
The hard choice between duplication, paralysis and chaos
A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate.
The larger truth is that we have choice between three evils:
Read more ...
Submitted by Johannes Brodwal on Mon, 02/09/2009 - 16:57.
The following is a trick I don’t use very often, but when I do need it, it comes in very handy. It’s a trick that many developers aren’t aware of, even though it’s been possible to do with JUnit at least since version 3.
Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests:
Read more ...
Submitted by Johannes Brodwal on Sun, 01/25/2009 - 12:59.
“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.”
If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.
Read more ...
Submitted by Johannes Brodwal on Sun, 01/04/2009 - 11:57.
Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now”? On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it?
Read more ...
Submitted by Johannes Brodwal on Tue, 11/25/2008 - 08:55.
I became a programmer so that I could spend time creating software by programming. I don’t want to waste my time managing low-quality code.
Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I’m sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers. However, it also means that I don’t want to have to go thought a long manual test myself to verify my code.
Read more ...
Submitted by Johannes Brodwal on Sun, 11/02/2008 - 15:58.
When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I’m talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.
Read more ...
Submitted by Johannes Brodwal on Wed, 10/01/2008 - 19:48.
It’s been a while since I promised to write top five unit testing tips, so I guess I should better start writing #2. As with my first example this one is based on a real-life story.
Your code is worth nothing if it can’t be tested. Change your code to make it more testable.
Read more ...
Submitted by Johannes Brodwal on Sat, 09/27/2008 - 20:47.
Warnings are useful. You get warnings from your IDE when you write something that might be a bug. You have probably made your program print out warnings or error messages when something goes wrong.
But too often, we down in the sheer volume of warnings. Then it’s impossible to separate the relevant and important warnings from the noise.
Read more ...
Submitted by Johannes Brodwal on Mon, 09/08/2008 - 17:50.
I’ve looked over some of my code lately, and found ways that I often improve my tests. I’m planning on writing a blog post for each of my five favorites.
Read more ...
Submitted by Johannes Brodwal on Mon, 09/08/2008 - 17:50.
I’ve learned the value of dealing seriously with connecting requirements to the actual code. The JBehave project started work to make formal, “business friendly” requirements into executable specifications, but due to limitations in Java, it was very clunky to use. JBehave 2.0 has just been released, and it has a much better model.
Here’s a specification:
Read more ...
Submitted by Johannes Brodwal on Wed, 08/20/2008 - 16:52.
When the building blocks of your program fail and you don’t notice, the problem can be very hard to diagnose. In most of my projects, the building blocks are the persistent objects. Using Hibernate makes it easy to create a data access layer, but if you don’t watch out, errors can sneak into equals or hashCode, bidirectional relationships or properties that for some reason don’t get persisted correctly. Or the code you use to search for your objects can be wrong.
Read more ...
Submitted by Johannes Brodwal on Mon, 08/18/2008 - 20:17.
After spending more time than I care to indulge trying to get commercial application servers to behave, I finally decided to Do the Simplest Thing that Could Possibly Work, and create a new application server from scratch. Well, not really a full application server. For 90 % of the Java applications out there, all that you really need is Servlets, so I limit myself to that. And not really from scratch.
Read more ...
