Blogs

Brian Foote and Joseph Yoder writing about software architecture (or the lack of it). Thanks to Bryan Boreham for the link.

A couple of days ago I posted some untestable code. I’ve had a couple of emails saying that people couldn’t see why the code was untestable. Here’s why, and here’s how to fix it. The code shown manages a list of listeners who are interested in being notified when the system date changes. It’s externally driven by calling CheckForChange(), this could be called in response to a timer event or from a polling thread, or whatever.

Finally finished reading Waltzing with Bears: Managing Risk on Software Projects and it was well worth the read. Waltzing with Bears is a book about managing project risk. It’s a slim volume, but packed with useful information. As usual, DeMarco and Lister present the topic in an approachable and readable way. The text is full of anecdotes that flesh out the theories with practical examples. In a nut shell; most project managers on software projects fail to adequately manage risk.

Three bugs went into a program; a memory leak, a misunderstood interface and a deadlock… The memory leak was easy to track down as it was in the code that was covered by the test harness. So we just instrument the code with Bounds Checker and run the test. A reference counted object was being mishandled and leaking. Easy fix. The interface issue was harder. I was using a std::list<> to manage a list of items and every so often needed to walk the list and remove some entries.

Given that the work I do goes on in my head and can be done anywhere I find that it’s often done everywhere. Anyone got any hints on how to switch off? Skiing and skating are good for me as I can’t think about other things when I’m doing them. Everything else always has the risk of being interrupted by an ‘a-ha!’ moment where a ‘work’ problem is suddenly solved and I need to scurry away to the study to implement the idea… And then you get in the flow and hours go by and you haven’t spent time with people you should.

We tried the new Carluccios on Upper Street on Friday night. Great food and excellent service. Back to watch the final Buffy (season 6) on DVD (so sad); glass or two of Glenfiddich, bug hunting and to bed. Up early to bug hunt and then skating in Kensington Gardens on Saturday morning. Back to get changed and then off to The Blue Elephant in Fulham for Hilary’s birthday do; more great food, left my unbrella at the restaurant :(.

If I don’t write enough blog entries then the way I have my CSS set up means that the front page starts to look ugly as the number of entries on the left side of the page shrinks and the columns on the right go all squigly… Is that why blog people end up writing these inane items that nobody really wants to read?

It’s easy to write untestable code. It’s natural. Most code that we write will be hard to test unless we explicitly think about testing when we write it… This code is really simple, yet it’s untestable. Why? DateChangeManager.h class CDateChangeManager { public : class Listener { public : virtual void OnDateChange( const CTime &oldDate, const CTime &newDate) = 0; protected : ~Listener() {} }; CDateChangeManager(); typedef unsigned long Cookie; Cookie RegisterForNotification( Listener &listener); void UnRegisterForNotification( const Cookie &cookie); void CheckForChange(); CTime GetToday() const; private : CTime m_today; typedef std::map<Cookie, Listener *> Listeners; Listeners m_listeners; CCriticalSection m_criticalSection; // No copies - do not implement CDateChangeManager(const CDateChangeManager &rhs); CDateChangeManager &operator=(const CDateChangeManager &rhs); }; DateChangeManager.

The code generation crowd are at it again. So, “writing code” is stupid is it? Well what will we call writing the requirements in a form that the code generators can understand and why will it be easier to get the requirements right? I like code generators. I couldn’t live without my IDL compiler. Or generators that write the grungy database access code or generators that make it easy for me to make SOAP calls.

A while ago I likened writing articles about code with pickling it to preserve it… It seems the last few days have been spent changing the vinegar… I’m moving most of my source to CVS. This was easy for the code that I had that was current; the Socket Server stuff and all of my latest clients. I’ve been working with all of that code a lot recently and it’s all pretty clean and consistent.