EDABlog

I just realized my main objection to heavy theoretical based development stems not from poor theory but in appropriate use.

I think it comes down to the original premise that 90% of a softwares lifetime budget is in maintenance  . While this is certainly true for large scale mainframe applications or software vender apps ( eg IE , Word etc) it is not for the majority of small apps  used today.  I have seen many of these applications not change for 90% of their lifetime and when replaced they are replaced by the latest and greatest language /technology.

Here is the thing i object to most - Using code that is very heavy in terms of  re-use and extendability but is difficult to read , understand and overly complex.   You can add to this the issue of developer skill level.  Now if i have a team of 10 skilled developers building a 2 year system , its certainly going to be a major system that will last with a budget probably in the 1-4M range . However for the more common typical smaller app with 1-3 people for 1-3 months it is important to follow KISS and keep the initial cost as low as possible.

Considering this scenario makes up the vast amount of development projects ( and most programmers work) its surprising it is neglected by academia , there seems to be very little advice in building small systems as cheap as possible -

Commericial vendors  have always embraced this market with VB , FoxPro , Clarion  all the 4 GL ( Progress etc)   but it seems sadly lacking in Universities and academia mainly because its not that interesting.  Instead of that make a graphic rendered in your Comp science course a better project maybe complete a simple 3 form and DB app with some master detail screens , you have 24 hours..  At least they would be more prepared for most workplaces.

The slowness of modern development has also caused frustrations between IT and business specifically business will want an application to try a business venture however after they jump all the hoops and standards the whole startup is likely to not be viable. I have heard many business people talking about a quick win , while ther are many examples i clearly remember a business person being talked into an expensive product , like an Adobe Sharepoint type app where , the business could code business forms in Javascript  and they would use the skills of the vendor for the first few form , laughable but you can see they want the quick win. While i knew nothing about the product I knew the organisation had no HTML or Javascript skills and know it will probably end in grief.  The lesson here is we need to provide a quick and dirty option for the business more often .