I was talking with a friend over the holidays. He was telling me how they are always in panic mode at work. They never get time to do anything properly, and they end up being surrounded by one off hacks that never quite get the job done. He asked if I had any input to maybe mitigate this.. One word, Interfaces.

What I mean by interfaces is simply this… compartmentalize the hacks. Take five minutes and look at all the different hacks that surround you. Find two that do similar things and look closely at them. They probably have some pieces that need to do identical things (perhaps they do them in an identical way, perhaps not, doesn’t matter) If you see a common step there, then break it out into it’s own script/class/function and give it a general interface that allows both hacks to use it.

Another way to create interfaces is to create them while you’re writing your hack. Look at the task… Break the task up into it’s discreet steps. Put a facade (also known as a wrapper) around any of those steps that can be used elsewhere.

Interfaces allow you to go back and fix a portion of an application without having to go back and rewrite the entire thing. It’s an integral part of the incremental development process. Nobody has time to throw away all of their code (nor should they, but that’s a different discussion.) However any project should be in some state of rewrite continually. This is only possible when you have a general interface to compartmentalize some of the functionality.

So how do you write the general interface? Well, that comes with practice. I would start with making an interface anywhere that you think it makes sense. You will most likely create too many interfaces. It’s not hard to remove an interface, so this is of little concern. As you reuse some interfaces, but not others, you can get a feel for the interfaces that fit your problem set.

Interfaces can allow you to compartmentalize your hacks, so it is less effort to go back and clean them up. If you’re finding yourself wishing you had time to rewrite something, perhaps breaking it up into it’s parts, and putting interfaces in there will allow you to take bite-sized pieces on. You can then go back and remove any excess interfaces you had. Eventually a rewrite is just an ongoing process.

An example of this is my current project. We’ve got three people working on a KDE application that is roughly 60,000 lines long. It has been 400,000 lines before. We’ve managed to refactor it down to that level. We’re progressing to our sixth generation now. This rewrite isn’t changing too many of the internals of the app. It is, however, changing it from a monolithic multi-threaded app that used plugins to extend functionality, into several small singlethreaded apps that work together to achieve the same goal. This rewrite has taken us a little over 1 man month so far, and it’s roughly 70% complete. We’ve been doing this in between tasks for the existing system, so it’s been very sporadic as well. The codebase looks like it will end up being roughly 30,000 lines when we’re done, and it will be far simpler to debug and maintain.

We’ve gotten away with 6 rewrites (actually more like major architecture changes) because we can reuse so much of the code we’ve previously written. Our interfaces allow us to swap pieces out as needed, and when we make a bug-fix, it doesn’t affect the entire system, but just what’s behind the interface. If that component is outputting bad information that affects something outside of the interface, then it’s pretty obvious and easy to track down.

Interfaces really can allow you to isolate problem areas. You can better respond to changing needs. It allows more agile development. And best of all, you can start reusing what works, and rewriting what doesn’t!

So Here’s to interfaces!

-Synwan

Well it’s been a while since I posted. Sorry about that. Things are starting to wind down a little bit, so hopefully I can get CXMLNode ready to distribute. I’ll post when it’s ready. In the meantime… Happy Holidays! Make sure to take some time to spread some good. I hope everybody has an enjoyable holiday season!

-Synwan

Lately I’ve been running into an interesting problem. We have a fairly large record based XML tree. We need that tree to act more like a database in that the same tree can be updated by multiple objects, concurrently and safely. The obvious question is why not make it a database. My reasoning for that is this XML changes fairly frequently, and we want to avoid having to convert the schema each time. XML allows us to easily extend the tree with no need to break the existing structure. We’re playing with some solutions, but none of them are far enough along to really discuss yet. However here are our goals:

• Concurrent (or very close) read access of the tree
• Concurrent (or very close) write access of elements in the tree
• Sane persistence of the tree (When a write happens, we don’t lose some other write that was just made)
• Generic enough framework that it can be used for any record based tree. Even better would be any XML tree at all.
• If it’s an existing solution, it must allow non-GPL use (BSD style is ok, or perhaps LGPL) and it must be affordable.
• It must not require external administration, processes, daemons, etc.

Lofty to be sure, but I feel it’s possible, so we’ll see.

-Synwan

About three years ago, I was hired by a company that develops a Linux distribution. I went, willingly, eagerly even. But I have to wonder, each step that is made is a bit of a gamble. Take .NET for instance. I’ve never played with it. I have no experience with it, other than reading the material that I track down. If .NET were to become the dominant development architecture, I would quickly find myself obsolete. Therein lies the quandry. How do you know which technologies to pursue? There are too many for any one person to stay current in. One could go with the path of least resistence, and just follow their career path, but that’s not really practical. One could burn themselves out trying as many things as they can, and avoid being a specialist, but that’s also not practical. So how can one figure out what to pursue, and what to leave by the wayside?

Well, here’s my myopic litmus test.

• Is the technology open, and utilizing existing standards where applicable?
• Is the technology applicable to a wide problem set?
• Is there real support behind the technology, rather than just a marketing blitz?
• Is the learning curve justified?

If you can answer yes to each of these questions, then perhaps a given technology is worth looking into. I’m sure someone has come up with a better test, and if so, by all means use it. I, however, haven’t seen it. Ultimately it’s all still a gamble. I just hope my number continues to come up.

-Synwan