This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Sense of Relevance
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
One of the interesting things you can see in software (probably anywhere) is the overly developed sense of importance many developers attach to themselves and their projects. Certainly we Smalltalkers are not immune to this; we often talk about Smalltalk as if it's the second coming or something :) There's a larger thing at work here though - it's touched on in this rant from the Bile Blog - and while the commentary there is a little rough, there's a good point hidden in all that anger - we often choose the complex over the simple for reasons that have nothing to so with the actual problem. Here's an example, related to me by a friend.
This guy has recently taken a new job - same kind of work he's always done, but with a different consulting outfit. During the initial process of looking at available projects, he's talking to someone about a job that involves getting data from a database, allowing users to interact with it, and possibly updating the database - you know, the standard CRUD thing. He asks what approach they are going to take, and is told that it'll use and EJB server, a big database, and a Java client - a three tier system. This is when my friend made the mistake of asking the following:
Question: How many users will this system have? Answer: 10 at first, maybe 20 eventually Question: Why not just use an Access front end to the database? Answer: Heretic!
He says that the lead developer on that project distrusts anything he says now. Stop and think about that, and about the general problem - most of the systems we build are not big. Most of them need to scale to small numbers of users, and most of them are simple CRUD systems. What do many, many developers immediately do? Over complicate them. Suddenly, it's not such a surprise that the failure rates for software development jobs are so high - we tend to over estimate the importance of projects and over complicate them
Take this blog, for instance - I've had a few people ask me what database I use, and they are often horrified when I tell them that I don't use a database. Why should I? I save the data in serialized object files, with the date of the postings encoded in the file name (one file per day). It's easy to find posts that way (the GUID is also an encoded date), and the file system serves things up pretty darn fast. I can back all the content (and infrastructure) files for all the CST blogs in less than 3 MB using a shell script. All my data is still in object form; I didn't have to worry about any impedance mismatch between Smalltalk and an RDBMS (or about db architecture issues, about which I know very little). Sometimes, simple problems only need a simple solution
I've seen the same sorts of things in many shops over the years. I recall one large development project in particular, on which I and a few other Smalltalkers consulted back in the late 90's. At its peak, there were 170 or so Smalltalkers, and nearly double that working in Cobol on a mainframe. Over lunch, a few of us determined that the entire thing could have been done with 2 dozen or fewer people, and likely in a matter of months - but that wouldn't have helped the management there build their empires. Well after I left that project, I learned that large parts of it had been outsourced. No surprise there - years of game playing and complexity adding had to be paid for at some point.
What's my point? Well, next time someone starts waxing rhapsodic over the need to use a whole set of complex technologies to solve some problem, sit back and ask yourself just how complex the problem really is, and shed any prejudices you might have about the issues of client/server development - it's really not the case that all problems require a 3 tier solution...
Previous Topic
