The online game approaches completion but recently the requirements were lacking and we couldn’t see the way forward.
We’re finishing the game play and getting to the complicated special cases - I’m hoping that they won’t be complicated or special once I understand them more… The original story that explained the latest piece of work was lacking when we analysed it closely; we fleshed it out and now I think we understand it enough to quote for it and code it.
We’ve been moving pretty quickly on the refactoring project. We had got to the point where we were doing at least two releases a week. Generally we would include user requested fixes in the first release and refactored code in the second. It started to become a little hectic. Last week we decided to slow things down a little so that we could regroup…
One aspect of the project is a currency exchange rate display.
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.
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.
Back in 1999 Darren came up with a cunning plan to make lots of money. The plan was ‘device control over the internet’… In summary, we didn’t.
Ideally this plan required an audio/visual link as well as a device control link. I decided that doing the audio and video ourselves was too much work and that we’d be better off using the NetMeeting data channel for our device control. We would get the audio/video stuff for free and wouldn’t have to worry about things like cameras and microphones.
