On Sunday 07 March 2010 08:25:15 Stephen Davies wrote:
> There is an interesting discussion on /. with the above topic.
>
> http://developers.slashdot.org/comments.pl?sid=1573922
Obviously, since it's Slashdot, I haven't read the article.
> This was all in 1977/78. Rewind to today and frankly there is so much
> obfuscation and framework usage that the size of apps has just gone
> out of the window.
We were having this discussion at work on Friday. When I started work
(1995), all I needed to know was C and a little UNIX. My first task
was writing an admin front end to a scanning application, so I wrote
a text based console app using Curses.
A few months back I was on a project with our new graduate which
involved writing an admin front end to a scanning application.
The core functionally is probably is much the same as the one that
got written 15 years ago, but now it's a web based application using
Java, HTML, Javascript and some AJAX libraries.
Before we stored the images on the file system, now the images
are being stored in a document management system, so there's also
the APIs for the EDMS that need to be known.
There's a lot more functionality expected by users these days
and the frameworks are needed in order to be able to provide a
solution in a sensible time. Writing everything from scratch
just isn't an option. Calling it obfuscation is a bit unfair.
Good use of frameworks can save time and produce better code.
Developer time is more expensive than CPU cycles these days.
> I see production code that is 'just cobbled'
> together. If it works then use it and god help the poor guys who
> have to come along and maintain it.
I've seen plenty of that, both with simple C applications and also
with framework laden modern applications. A lot of the time it comes
down to changing user requirements and too little time provided by
management. Then you get customers who take a look at the project
plan, and complain at time being spent in testing and documentation.
There are problems at all stages of the process - it's not *always*
the fault of the poor bloody programmers.
The problem I think is because there's so much requirement to learn
high level 'stuff', less time is spent at University being taught
the basics. Businesses don't want a new graduate to be able to
understand how a compiler works, or how TCP/IP does error handling,
they just want someone who knows APIs X, Y and Z and has experience
working with products A and B.
At least, that's been my experience.
> Needless to say, I politely declined the contract.
> When the asked me why, I replied, "Because your core system is
> frankly unmaintainable".
There's been a few projects where we were actually given time to
re-write a system and make it maintainable. Generally only after
much money had been spent trying to maintain a bad system however.
> As one /. post states, Programmers are a dime a dozen but good
> programmers are worth their weight in gold.
Many programmers are business people who know how to write VB
macros in Excel, who end up being told to turn their spreadsheet
into a business critical application.
--
Be seeing you, http://www.glendale.org.uk
Sam. Mail/IM (Jabber): sam@???
