General discussion

Locked

The cause of the degradation of programming

By Jaqui ·
In the Discussion about MS targeting apache,

http://techrepublic.com.com/5208-6230-0.html?forumID=85&threadID=175795&start=0

A side ceoncern about programming came out.

did ms's basic, visual basic and simple programming cause the degradation of programming from an elite skill to glorified macro writing?

after all, we all know that writing sql queries for mssql, oracle, dbase, mysql, postgresql, interbase, db2......... is now concidered high programming skill, yet in reality, it is little more than a basic part of any office clerks job.
create the queries to get the data you need from the database for the report you are generating, or correspondence you are putting together etc.

is not programming creating the application, such as orcale server, mssql server etc?

how did general clerical tasks become concidered programming?

when are we going to remind employers that macro scripting is for general office staff, programming is creating the application the script runs in?

This conversation is currently closed to new comments.

170 total posts (Page 3 of 17)   Prev   01 | 02 | 03 | 04 | 05   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

I think we are seeing it happen now

by HAL 9000 Moderator In reply to Progression...

With all the Outsourcing happening we are seeing the lower end of the IT sector loosing out and what is left is again beginning to start being called IT.

It takes a special type to sit a a help desk all day and deal with the general public who think that they know far more than they actually do or are so peeved off by some previous complaint that they just have to take it out on the poor person on the other end of the phone line. I know that I couldn't do it and stay even the little bit sane that I currently am. It was bad enough when I only answered calls that others couldn't handle so I missed most of the problem ones and only got the real ones where I could help or at least try to with some of the problems that arose.

But even still though these people have a definite skill set they really are not IT Professionals but only involved as First String Support. The same goes for the bulk of the HTML coders that we used to see around as well as a lot of the Basic coders.

But I do object to being called in just to change a DB template because there are no qualified people around who understand how the program works to make these minor changes or even write a Macro. The fact that companies are willing to pay me to do this type of work I think tends to point more to the lack of skill within their organizations. With the small business I don't really have a problem although I do try to stay away from their accounting packages but I'm inevitably called in to fix those as well.

But with the larger organizations they seem to lack the skills to do the work themselves and this is a worry as it shows just how dependent they are on outside assistance while being under the mistaken impression that they are self sufficient even for the very basics.

A few years ago I used to sell a lot of the Learn Key products which where heavily used as a training aid for various companies but today even this seems to have fallen off dramatically as these places seem unwilling to even consider wanting to train their staff and while the Learn Key products where good they where not the great products that showed everything possible I just considered them as taking the end users to a stage that was considered as a basic requirement back in the DOS and early Windows days that was up to 3.11.

After 3.11 was replaced by 95 the requirements to learn seemed to drop off dramatically and it seems to have been in a steady decline ever since. The fact that OEM MS Software generally doesn't come with even a manual tends to make a lot of people think that it is easy to use which the basics are but they no longer seem to realize that there is far more that the software is capable of performing and just no longer try.

Maybe I'm wrong but as the MS manuals have shrunk so it appears to me has the end user knowledge of the products.

Col ]:)

Collapse -

Well I don't know whether

by Tony Hopkinson In reply to Progression...

we are seeing a progression away from scripting technologies, certainly not from ms anyway.
The any fool can write a program approach has certainly been good business for certain interests.

In the UK though I do believe we are starting to see a business reaction to the cost of this watering down of the discipline.

The slump within IT we've been going through has resulted in a very low level of investment, no attention to refactoring and a hurried series of what I can only call bodges.
Bearing in mind a lot of this code was written by the boom generation with tools that were not designed to code properly but cheaply, there is a shedload of very low quality juvenile code out there.
Now with six years of bodges in top of it what I'm starting to see is a business realisation that quality coding not only gives you a quality product, it gives you a competitive edge and a long term cost reduction.

I think the tools and the boom went together, probably the slump as well.
A whole raft of people were introduced to programming, unfortunately the tools they learnt with weren't the best, their training wasn't the best and on top of that a lot of them entered IT not out of a vocational desire and talent, but because they could and it payed lots.

Based on the evidence I've seen a lot of them should have been prosecuted for fraud.

You can (well I can) write good code in scripted and or drag and drop environments, the thing is, if you don't know how, you don't have to. Using the old text source compiled applications your scope was much more limited in this regard and the skills required by the environment were much greater. Equally there's no doubt a comptent programmer could write this code much better in the old environments, though of course it would take considerably longer.

Collapse -

the problem with the drag and drop

by Jaqui In reply to Well I don't know whether

isn't that you can write good code, it's that you don't have to.

the majority of drag and drop code is bloat that isn't needed, yet is included in the final executable.

this comes from the libs used, after all if you need a function, use the lib that contains it, then use 35 other libs for one or two functions each.

if they were to build a lib or 5 with the functions they are using, then a lot of the bloat would go away. naturally, this would mean reading the function to see what is requires also, as it may need 3 other functions from same lib. the other 11 are bloat.
( auto configuration / generation of makefiles don't always optimise compiler instructions for final size, and with dynamic loading libs, the extra functions are included even though they are never used. )

Collapse -

Drag Drop ... Good Bad

by tagmarkman In reply to the problem with the drag ...

I have a lot of mixed feelings of Drag and Drop. I agree it causes a significant amount of code bloat, no doubt about that but I've seen more code reuse with drag and drop than I ever have with straight coding. You can certainly do better code reuse and better coding without it but the nature of most coders simply don't.

However, I suppose that is what this thread is about, did this contribute to a watered down workforce, lower wages, etc...

Probably, but I also believe it has a lot to do with entry level engineers accepting extreamly low wages to get "experience".

Collapse -

maybe so,

by Jaqui In reply to Drag Drop ... Good Bad

but if you are a software engineer, would you really concider macro writing experience? or a job until you can get into software development?

maybe it's a bit of both.

using a drag and drop for designing the interface definately makes sence, but what other libs you need shouldn't just be a reuse code lib, they should be built for the specific application.

the bloat from them is the fault of the user, not the tool.

Collapse -

I'll agree

by tagmarkman In reply to maybe so,

Initially, yes, I would consider macro writing the very first "taste" of programming. Our job is about automation and Macros are certainly automation. However, I certainly wouldn't call it software engineering by any stretch. Macro writing for program experience should be very short lived (diminishishing returns on knowledge through experience on writing macros are quick in Macro writing). I suppose that goes with the job as well... writing macros until you can break into software engineering.

Then again... I have seen people make their careers out of macro writing. They understand their limitation and can be quite valuable to a company as long as they don't think they can suddenly become a software engineer overnight with only macro experience. Saddly, many think they can.

I agree that drag and drop is great for interface design... (I also see limitations in that as well) but as far as RAD is concerned, I'll agree.

For drag and dropping code snippits (asside from skeletons), I'm with you on that, I think that it creates bad programming habbits, however, if coupled with a component, I can see benefits in certain situations.

Collapse -

That depends on your definition of

by Tony Hopkinson In reply to the problem with the drag ...

good code, though doesn't it.

I'd be the first to admit drag and drop is not elegant, it is however extremely pragmatic.
Good code by my definition as far the bulk of my practical experience goes is readable, extensible and maintainable as well as meeting the requirements.

I don't feel that's drag and drop though, it's OO. The more extensible you make a class, the less it does. If it isn't extensible at all then there's no point inheriting from it, therefore it's bad OO, because you would have to rewite those bits of the class you wanted instead of re-using them.

The degradation isn't OO as such. I know a lot of developers who wouldn't know where to start without OO, even more appallingly they don't even know what OO is and why and end up writing bad OO designs with the attendant bloat.

My chosen language is delphi, but I've met very few developers who know how to optimise their design to cut out unnecessary code in the executable. Saying that my knowledge is mainly theoretical as I'm never afforded the time to apply the techniques in the job anyway. In fact If I was required to do it now I'd have to research again because that sort of thing is specific to the compiler not the language.

Collapse -

The good code....

by tagmarkman In reply to That depends on your defi ...

Ah Pascal... there's a language the new guys get lost in... that and Fortran... :) For some reason they ignore the fact that both of those language are alive and kicking... Even Cobol..

Definition of good code... That's the main difference of RAD development and more elegant solutions. Quick development has it's place. But it's up to both development and management to agree what needs to be done for the goals of the company and client.

Personally, my business doesn't optimize anything until we stamp the product as code completed to specification and we met the minimum of test bar. After that, we'll shoot for optimization. We usually have time to do that for about 25% of our new products and about 75% of our updated products.

Collapse -

Optimizing something that

by Tony Hopkinson In reply to The good code....

doesn't work or isn't finished is a newbie mistake.
I should point out that I don't do RAD, even thought the tools were designed for it. RAD all too often concentrates on the front end while sacrificing any semblance of quailty behind the scenes.
I use Drag and Drop to quicky do front ends but I do it in conjunction with the back end code, that way they don't get out of step.
My development method is effectively functional iteration. I add a a ui and the backend for new functions, and any refactoring of existing functionality in each pass.
It's the way I learnt and all the gatekeeper crap left me unmoved.
RAD = QAD in practice as far as I've seen.

Collapse -

Drag and Drop GUIs

by tagmarkman In reply to Optimizing something that

Drag and Drop front ends with back end code is still what I consider RAD. In fact, I can develop program much quicker the way you describe than editing properties.

I think drag and drop UIs are fine for internal or quick development. I feel they are great for many projects.

However, for truely professional products, I rarely see good components (although there are a few out there especially when it comes to generating report data). I say this because my people in the usability lab almost always pulls their hair out when drag and drop UI programs are handed to them. They almost always tend to be "program interfaces" and not "user interfaces".

Back to Web Development Forum
170 total posts (Page 3 of 17)   Prev   01 | 02 | 03 | 04 | 05   Next

Related Discussions

Related Forums