Business Systems Developers Have A Bad Name
Agile, Scrum, Fancy Words For Writing Software That Delivers
No matter which way you look at it, in general terms business application software developers have a bad reputation. Systems are almost inevitably delivered late or even not at all. The average user in the average company will spend quite literally hours every week bitching about the computer systems they are forced to endure. “Why’s it done that?”,” What the hell does that mean?” are a couple of the things that I hear on a daily basis.
I spent years writing business systems, in the most part users were positive about what they were getting and using. Systems written to an initial specification, tested to death and then adapted as and when required at an agreed cost if needs be. Ongoing support for the client, sustained income for the software company was a winning combination. The initial specification based on a detailed requirements analysis would always be a functional overview and would not contain any code specifics, I think I used pseudo code once (when I was writing games). “This is what we need it to do”, was usually good enough for me. Other than that, it was some user interface mock-ups and a lot of database design and away we go. The testing and ‘tweaking’ phase of the development life cycle was all important. Systems were generally delivered on time and worked.
These days (I never thought I’d say that), everything systems related is about planning, more planning and then reusability. What appears so alien to me is that so much of this planning is not to meet a functional requirement but rather to detail how and why we are going to write what we write when we write it. Hope that makes sense? Why write something in 10 lines that you could do in 1000 on the of chance you “might” need to re-use it 2 years down the line? On a personal level I have never written anything that I could not re-write better 2 years later. I am always learning and improving, when I look back at code even 12 months old I often cringe. Looking at job adverts it’s easy to get lost in the methodologies and skills being asked for, is it humanly possible for one person to know so much I often ask myself? Another question being do they ever produce a product? With all this planning and worrying about re-using code does anything ever get done? I know of a company that hired academic developers that were so busy concentrating on design that the company went under before any product was even close to ready, seriously! How many delays can we expect people to tolerate, the testing phase was never an issue there! Why should the company paying us for a product be expected to pay for code that will be used again and again in later projects not for them?
Don’t get me wrong, I’m not saying planning is bad, it is an essential part of systems development, but it’s not the only part. Maybe I’m old school but the part I enjoy is actually writing the system and having it work. Ok, I know that systems are getting bigger and more complex all the time. Large teams of developers are the norm. It’s just that I think that no matter how much you plan, visualise and brain storm something will always be missed. We are striving for the impossible, perfect systems, but in the worst cases we are actually delivering no system. Don’t believe me? Look at Microsoft. Imagine the man hours that go into planning any of their applications? How often does a new bug or vulnerability get discovered? Why weren’t these thrashed out at the design stage? It never even crossed the mind of the development team that “vulnerability X” could even occur. Putting it simply, with anything more than the most basic of systems it is almost impossible to plan for all eventualities no matter how logical you are. How come they are not found during testing? Is the solution here old school development, less time planning (talking), more time writing and testing? Less time worrying about re-using code more time giving the client and customer a working product? Would Microsoft be better or worse of if they spent less time planning and more time testing? In Microsoft’s defence they are very good at patching, I suppose they could be seen as using us as the testers. Just maybe if they spent more time doing proper testing we wouldn’t need to test for them?
The worst example of over planning I have yet to come across is a financial system I use on a daily basis. This system cost millions of dollars to have implemented, years of planning and who knows how many consultants. It is written by one of the biggest players in the software industry, adapted by a specialist software consultancy. The end result of this is a system that is virtually un-usable and not too far away from being replaced by an of the shelf product. It is so bad at the lowest level that even a miss-placed mouse click will hang the application. I can’t believe that this system was ever tested prior to hand over. It was very late being delivered as it was, the reason being a longer than expected “planning cycle”. What it does is not that complex, it’s just that it has obviously been planned to the point where implementation has been a rushed after thought. All of this planning hasn’t even resulted in a system that would meet the basic functional requirements of its users, but heh, I’m sure they’ll be re-using that code somewhere down the line.
Anyway, I have just started a diploma to help me understand why using several different planning strategies is so important. Why write in 1 day what I could spend a month doing “properly”? I know that I’ll read this back in a couple of years time and wonder what I was thinking; either that or I’ll say to myself “wow, that’s when I actually used to finish what I was writing”. Seriously though, I’m sure by the end of it I’ll realise where I’m going wrong, in the meantime I’ll just carry on writing applications using my RAD style (I’m glad it has a name!) that whilst not to everyone’s taste, works just fine for me.
n.b. Who’d have guessed it my approach to development has a name, it’s classed as a Agile Methodology! Here is an excellent article that explains agile methodologies in some detail.