Category: Working Software

Refactoring a House

Some of you may remember that I started a house construction project. Things are moving very fast, now, and the actual construction may take less time than it took to get all the necessary permits. So far, the project’s about 100% over the time budget. And people say that software development should be more like the construction industry!

But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.

This post is about an example of refactoring found in the house construction domain. Read More

It’s all code

I’ve never really liked stored procedures. I always put it down to the fact that I’m a programmer, not a database person. I like keeping the functionality in the code. The database is just a place where objects go when they sleep.

My current client uses stored procedures for all database reads and writes. It probably made sense when the code was ASP, but Java JDBC code has all the expressibility you could want.

Today, I learned a new reason to not like stored procedures. Read More

Making software visible

I was reading Jerry Weinberg’s book, Quality Software Management: Vol. 2, First-Order Measurement, and came across the following:

Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.

This got me to thinking, as Jerry’s writing generally does. Read More

Making TDD and Java Swing behave

Recently, I wrote about using the JfcUnit and Abbot frameworks to test-drive the creation of a Java Swing GUI. Since then, a post by Liz Keogh on the ExtremeProgramming yahoogroup led me to another option. It a wrapper around Swing written in conjunction with JBehave, but as Liz points out, it’s not dependent on the framework and can happily be used with JUnit, also. I like the fact that it’s really lightweight and fast. Read More

TDD and Java Swing

It’s been awhile since I’ve written any Java Swing code, and doing so now is making me feel a little stupid. Test Driving the development of Swing hasn’t improved much since the last time I did this.

Back in 2003, Jeff Waltzer and I decided to experiment with TDDing a Swing application to see if GUIs could be test-driven. It wasn’t always easy, but we convinced ourselves that they could. We started out rolling our own Swing test framework, but soon found ourselves immersed in AWT threading issues and Swing peculiarities. So, since we seemed to be headed down the road of reimplementing JfcUnit, we decided to switch and use the real thing. Read More

TDD and Exploratory Testing

I’ve often found that Developers and Testers misunderstand each other, even when they have a congenial relationship. (And in some shops, the relationship is anything but congenial.) Developers often don’t see the value of the Testers, or get annoyed that the Testers find issues that weren’t mentioned in the requirements. Testers often think Developers only consider the nominal cases, and don’t give enough attention to the edge conditions. Often, neither understands the others point of view. Michael Bolton, on the agile-testing list, said, Read More

2 Comments

Categories: Working Software

Tags: ,

Just one of those things

I’ve been neglecting this blog, lately, partly because I’ve been busy working on a software development process assessment for a client. In doing this, one of the meetings I observed was a post mortem of a release failure. The developers involved noted that they’d seen some connection drops by the webserver on the integration environment. The developers, however, didn’t trust that the integration environment adequately represented the production environment. They’d seen a similar problem some months prior, and didn’t know if anyone had fixed it. Therefore they didn’t know whether these problems were the result of the code they were deploying, or, as one developer put it, “just one of those things.” Read More

2 Comments

Categories: Working Software

Tags:

Learn the trade and the tricks will follow

I’ll never forget the 11th grade English class when Mr. Ervin departed from his usual lessons in literature, and lectured us on this topic for the full hour. “Learn the trade and the tricks will follow.” As he repeated this simple advice, he bemoaned the fact that everyone was looking for the shortcuts, looking for the quick and easy, trying to bypass learning any more than was necessary.

Where did he learn this advice? As a carpenter’s apprentice, he had noticed that the master carpenter always had some little trick or technique to apply in difficult situations to make them easier. Carpentry was hard work, and he though if he could learn all of these techniques, it would be much easier to learn. So he asked the master carpenter to teach him the tricks of the trade. “Learn the trade and the tricks will follow,” was the reply. Read More

3 Comments

Categories: Working Software

Tags: ,

Interface between Domain layer and Persistence layer

What’s in a name?

I happened across Debasish Ghosh’s post “Inject Repositories, not DAOs in Domain Entities” and it triggered a few thoughts. In this post, he suggests that the Data Access Objects that perform database reads and writes should be wrapped in a Repository wrapper to isolate the domain layer from the details of the persistence layer. What do I think? Well, yes and no. Let’s look at this in a little more detail. Read More

Testing that no errors remain

On the Test Driven Development YahooGroup, Alan Baljeu asked, “It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature…. And by not considering those things, you introduce bugs into the software.” In response, he got two types of advice. One was specific suggestions of software construction techniques that can reduce the occurrence of errors by reducing the number of places that need to change when adding a new feature.

The second type was general testing advice. Alan admitted, “I don’t see a way to properly identify what new behaviour will need to be covered. I want to be sure I’m not forgetting cases, but currently I’m overlooking too many of these effects.” In other words, the current test coverage is not catching all the errors. Read More

4 Comments

Categories: Working Software

Tags: