Mechanical

Approaches to Managing Software

I've just had the most interesting meeting with another developer who needed to figure out a solution to a complicated problem. His solution was a caching strategy with synchronization issues. He had three separate processes which must be run in sequence and at the end, the only way he could figure out if his information was stale was to refetch the data he was caching. I was totally confused by the approach. When a solution is complicated and non-obvious, it's time look at the underlying design. He wanted to solve the problem and I wanted to simplify it. As it turns out, one minor change to our system eliminates many of the problems he was facing.

When faced with a complicated problem, I can't understand why someone's first instinct isn't to step back and say "what problem are we really trying to solve and how can we make it simple?" That should almost always be the first approach. When you can't solve it, simplify it.
When I did any programming(seems like centuries ago, especially if I mention ADA85, Turbo Pascal, REXX, or any of the other good stuff), I always asked myself a couple of questions:
1. What kind of data/input do I have?
2. What do I want out of it?
3. Can the dataset be simplified?
4. What was the previous programmer thinking?

One example is a simple 'archive registry' for large drawings I had the misfortune to be asked to 'update a bit'
In it I found a 'special' table with two columns.
Both columns were text strings.
And the contents?
'Format','Folio'
'Format','A1 Halved paper'
...
'County','Oslo' (Oslo is both a town and a county. )
'County','Finnmark'
...
'DrawingType','Structural Bridge'
'DrawingType','Electrical Tunnel'
...
And so on...

I fixed the problem they needed fixing(a couple of communes that needed to be added to the table. And yes, it also had most of Norways communes - about 1500 - in the same table), then told the bosses that I would under NO CIRCUMSTANCES do any more maintenance on that application, EVER.
The sad part?
The guy who made the application - he had moved onto other tasks in the department - told me that he didn't really have time to do it right when he designed it.
The REALLY sad part?
The same server that houses the database also contains a database(bought from the post office, with annual updates) complete with all county, commune and village names in the country.
It would actually have taken him less time to hook it up to the application than to do a botched import into his bastardized table and working against that.

We have another system at the office that was completely useless when it was introduced. Made lots of pretty reports, but the users could barely enter their data. In fact they had to enter some things that were known constants(Well, known to anyone in that field). And the 'project coordinator' at the office? Not only was he a manager, but he also 'sorted' the feedback to the developers, removing 'trivial errors' and such.
What we got was a VB frontend for an Access database, with lots of tables(we all know that access doesn't like too many tables... ) that had to run over the network. Over a slow link, even...
The users went back to their ancient DOS-based Lotus 123 spreadsheets...
It's in its third or fourth incarnation now...
The users tells me that if I ever even consider replacing the ancient HP LJ2100 they have(ext to the shiny color laser), there'll be hell to pay as it seems its the only one that prints the reports they need, properly.

I could keep listing, but...
We have more than 350different applications in use.
(That includes, MS Office, Acrobat(7,8,9, both Standard and Professional) AutoCad, and a few other 'shelfware' items, of course)
Also, client-side HTTP caching servers
I have had a run-in with a similar thing when I thought about this post: http://insanecoding.blogspot.com/2009/10/distributed-http.html

At first, the idea of a distributed web caching system is interesting. The idea is to reuse browser caches of previous visitors to scale low-end home web servers. The proposed solution, I think, uses client browsers as caching servers.

Now, you could make this system work as advertised. However, the more I thought about this, the less I liked it. For one thing, web browsers are not necessary on all the time or even on enough to be usable. The proposed system would spend a lot of time just checking to make sure the cache servers would be available. More importantly, there is something distasteful in mixing clients and servers together. A P2P service one thing, but the web architecture has already been clearly defined.

In any case, this post is merely a "me too." Complicated design often suggests misunderstood requirements or at least a limited view of the problem.