Reusable classes

Today, my pair commented on how we have gotten a lot of use from our test-helper classes. How true, how true. Over the course of the last year, we have created the classes needed in by our application, and the tests to support those classes. But we didn't stop there. We also created many small utility classes to support our tests. These classes are barely worth writing, or so it would seem. They are actually priceless.

We have gotten a lot of re-use from these classes because they are small and concise. They each address and encapsulate one sole responsibility. The classes usually consist of two or three methods, and are no longer than about twenty lines. It's in this precision that they find their utility. Being small and to the point, it is very easy to pick the right class when needed.

We've developed classes to set and reset system properties; to set and reset logging levels; to read and write private fields; to set id's on our domain models; and many other small responsibilities. At first, when developing these helpers, we would wait for a duplicate need to appear, and then factor out a re-usable component. As we got better at this, we wouldn't wait for a duplicate need, but instead would factor out responsibilities as we saw them appear. This helped us get even more utility from these classes. As soon as the classes were created, uses for them would appear.

By encapsulating concepts, keeping concepts small and concise, and identifying concepts early, you will increase your chances for re-use, and get a lot of mileage from your classes.

My takeaways from this experience:

• encapsulate responsibilities
• create small classes
• factor responsibility early

Hindsight is 20-20, even several years later

I ran into an old colleague, Alex, on the train today. We went through the usual catch up conversations, and got into talking about some of the old projects we had worked on together.

Alex mentioned that an old application that I had worked on along time ago was still being used, and the code still maintained. Our project was a banking web site, and this application was a supporting application that was used to verify and enroll users into the main application, which was a java web application. In typical hindsight is 20-20 fashion, we started to comment on how we might have approached that application differently.

To appreciate what we would have done differently, I guess I owe a little background on the application. The original enrollment application was a Lotus Notes application, and it verified the enrollee information against the account database. When lookups against the account database started having performance problems, we decided to "quickly" fix the problem by replacing the lookup with a PowerBuilder application. After some modest success improving performance, we decided to fully re-write the enrollment application in PowerBuilder. The application was written along-side the main application, with little design, little visibility and little testing. Despite that, it was deployed on time, and it worked.

Looking back, I would have made this a full-fledged and visible project. The enrollment application, by its nature, has a lifespan that matches that of the main application. This alone should have been consideration enough to give the enrollment application more visibility.

Alex mentioned that maintenance of the application was passed around from team to team. In hindsight, I would have implemented the enrollment application using the same technologies as the main application. The enrollment application was written in PowerBuilder, by a couple of team members, while the rest of the team was working on a Java web application. This would bring the technical skill set in line with the main application, improving the chances of maintaining the application.

I mentioned increasing the visibility. To me this means two things: more project management visibility, and more testing. Over the years, I've seen that detailed visibility into the details of a project, and into the true status of tasks, leads to more successful projects. In part, because developers tell it like it is, and in part because managers can see the details for themselves. This outcome of the original project may not have changed, since the application worked, but the process of getting there would have been much smoother. The same goes with more testing; the outcome may not have changed, but the project would have gone smoother.

Finally, when the PowerBuilder application was first developed, it was thought that this would be a short-lived application, to help with performance for a short time, and then the application would be retired. Of course, it is still not retired. In hindsight, I would have approached even the smallest effort with the same rigor as an application planned for a long lifespan. You never know when an application will take on a life of its own, and outlive everyone's expectations.

Where have I been?

I need to thank my friend Tom for getting me back to writing. He's doing a craftsman spike to refresh his learning process. Talking to him got me back on track about documenting my own learning. I haven't been documenting lately because I've been studying. I'm 3 classes away from getting my Master's in Software Engineering at DePaul University.

I started looking into this a couple of years ago while in a rut. I wasn't inspired by my work. The problems were interesting, but I wasn't. Instead of solving problems, I spent a lot of energy trying to muster up the inspiration to get into the problem. Up to that time, all of my programming experience had been on the job, so I thought that some formal study would jump-start me. A year and a half later, that was a good decision. I've learned things about the how software is developed, as well as how software can be developed. Best of all, I again look forward to getting up and going to work; to solving problems; and to learning a little more each day.

To give myself a best chance to succeed, I will need to combine all of what I've learned on the job, everything I've read along the way, and what I've learned in my course work. There are some great SE practices that can help move your project forward, as there are some great practices and trends from the field, along the lines of agile methods. It's to cross-pollinate some of these ideas, to mix and match practices and techniques, to upgrade our toolbox for development. I plan to share some of my ideas on this....soon.