What to look for in an accounts package vendor.Part #3. By David Carter

I don't think Mr Brooks and I occupy the same planet. The devs I come across and work with are incredibly motivated to build the best stuff they can. Check out the 950 bodies that turned up at BarCampBlock last weekend. Check out attendance at OpenCoffee Club each Thursday in London - usually 50+ each week. As a movement, OCC has spread around the world like wildfire.

I'm witnessing one of the most vibrant and creative periods of development I can recall. Stuff gets fought over but it's done in a spirit of cooperation and a desire to see software advance. If you're a serious code jock then you know that's how great development proceeds.

If it was any other way, open source would be dead on its feet. 11 million downloads of mySQL tell a different story.

If it was any other way, then SAPs SDN network of 800K developers and others interested in what they're doing would be a disaster area. It's not.

The notion that a single person knows it all is plain nonsense. Open source is showing us how the creative baton gets passed on and around.

I have meet software companies who delude themselves in this manner before. Nothing new. Along with programmers, designers, managers etc. to busy/lazy to read the documentation and always looking for the quick answer from somebody else.
The resulting software is no better than anybody elses but suffers from being designed by a committee. A committee lead by the egos of managers who believe they are in control of a situation, when is essence the programmers/designers have passed the point of caring and just look forward to the next pay cheque.

I have seen some of the issues described occur in software projects in many different industries, not just accountancy. They are common problems wherever software design is not properly managed.

Fortunately, this doesn't happen in all projects. It is possible to transfer design knowledge, provided the people responsible for this have the skills and motivation to do so. Often, this is left to the person on the project with the most design knowledge. This person is more valued as an individual if he or she fails to pass on their knowledge, so they have no incentive to do so and it is low on their list of priorities. Having worked this way for years, they may have never developed the skills either. It isn't always this way, as some individuals, and some organisations, understand the importance of communicating the design.

So, if you are choosing between badly managed software packages, it is probably wise to choose the vendor who retains their key staff. Personally, I'd prefer to buy from a vendor who manages their software projects well, but as an outsider, it is hard to tell which is which.

To Robert Brook: Your decription of software history is hopelessly inaccurate and I hope I don't become a customer of your software. I'd hate to think I was beholden to 1 person the way you describe. Thankfully, the s/w development world has moved on from this egocentric view.

I believe the term used at Microsoft is system architect. Nobody is suggesting Norman Foster fits all the door hinges. As for open source - can you point me the direction of an open source package for completing my UK corporation tax return ?

The first couple of comments seem to cast doubt on the truth of Davids article.

Having been closely involved in the accounting/software/ERP industry for some years now, I do not find or see anything unusal in what David writes. May be a point here or there is stetched a bit, but in essence it is quite true.
Why!
Because when developing software systems there has to be a KINGPIN able to make quick decisions, around which the whole development hangs. The person who sees and understands all the nuances soon becomes that KingPin - they may not start out as that, but very quickly they become the 'guru' to whom all others turn for a quick answer.

I prefer the term guru to megabrain.

With some software products, this tends to be 1 to 2 people. With SAP it was the original 7 or 8 founding fathers of the company. Which is why as that product has matured we are tending to see an increase in the occurances of changes being made in one area that have an adverse effect upon another - why because the 'gurus' have moved on.

As a software developer myself, keeping it in your head is far easier (and faster) that writing it down. For the mere process of writing things down slows up the 'creative flair' to the point of destroying it. Pure concentration at key moments is what is required - ignoring all distrubances - cups of coffee, questions from colleages, the clock, telephones, fire alarms, etc. Only when the 'circle has been squared' and all those loose threads tied in can you afford to relax and put a few thoughts down on paper.

Believe me its how the industry works. And if it doesn't work, you end up with a second rate product.

Bob

"So behind every accounts package, even from the biggest companies with hundreds of programmers, there are usually just one or two key designers, sometimes only a single individual, who understand the whole thing as a unity. "

Please provide examples.

There is too much inaccurate generalisation in this article.

Does anyone believe this? I'm rapidly concluding that the author of this stuff makes it up as he goes along.

My team are working on it but I doubt we'll make the code open source for the time being because we are developing services around it and it's not yet clear how we could separate our 'secret sauce' away from the commodity piece I suspect you're after.

If you'd like to see where we're up to, then check this 2 minute video which was recorded by my CEO. Might make you scratch your head?