Too many people programming

This is a discussion on Too many people programming within the A Brief History of Cprogramming.com forums, part of the Community Boards category; An interesting article at artima today for those of you not getting the newsletter
http://www.artima.com/forums/flat.js...&thread=186478
Despite Bjarne apparent conclusions, I ...

Too many people programming

Despite Bjarne apparent conclusions, I also add too many people programming as being one of the problems with programming these days. Executive decisions are made mostly based on current resources. An host of mediocre underpaid code typists can certainly speed the development process in comparison to a small bunch of quality programmers. They will also make it cheaper.

The problem of programming is in part being widely accessible to everyone. And don't even think for a minute I'm being elitist. I'm a code typist, not a programmer. Not even in Visual Basic where I spent many years getting payed to do it. I just happen to know what makes a Programmer (capitalized) and what not. I'm aware of my limitations and live with them.

Will this problem get better? Nope. I don't believe it will... The KISS principle of programming languages design, the programming for the masses ideology, is pretty much what one is getting for the past years. However that is all BS. And no, that's not Bjarne initials. Not even for a moment someone with a forehead the size of two fingers will think that doesn't come with consequences. You cannot just add Simplicity to Power and expect to get Powerful and Simple. As appealing as it may seem to product managers of the major players in programming language design industry, it is really trying to make gold out of lead; it won't happen.

Sure, that is the objective. Clearly slowly and carefully evolving a programming language to become ever more powerful (read, efficient in an elegant manner) and simple should be on the agenda of any of the players (personally I think C++ does it the right way). But never by compromising one for the other. "There is no way you can do that!", I hear some of you probably saying. Well, true. Probably some things can't. Remember the lead analogy?

Another problem is the fact that none of the code typists is being told that different problems may mean different programming language solutions. This idea that one size fits all is particularly heavily distributed by those private companies pushing their own home brew programming languages... not always exclusively for commercial purposes. Someone who thinks they are a programmer becomes a zealot of one language by the marketing surrounding it and the other code typists who preceded him or her. It's like football and politics. You can only like one programming language and you must shun all others. But The Programmer knows the truth and knows more solutions than there are problems... he or she of course also expects an higher pay.

And down back we go to managerial decisions. A bunch of code typists that can do the work of a smaller number of highly expensive Programmers and do it twice as fast seem the right solution. Especially for those companies expecting to also sign a maintenance contract, or those expecting to capitalize from version 2 and 3 and 4 and 5,...

To the rescue, reinforcing the decision, the "simple" and "powerful" programming languages and the host of cheap code typists that operate in them like me.

>The problem of programming is in part being widely accessible to everyone.
I don't see it. While that may appear to be the problem, the root of the problem is education. Programming is widely accessible, but good training isn't, and the result is a slew of under-trained semi-programmers with a quarter of a clue. I don't think that shrinking the pool of programmers is a good way to make up for a lack of good teachers.

I think programmers often learn from experience. Even if the programmer knows about lots of Algorithms, lots of Design Patterns, etc, in theory, if he hasn't programmed at all, he won't be able to know how to use them properly.

I'm with Bjarne on this one, it's the pressure facing programmers. People in industry will just hack together whatever works now, despite how it should be done. I think the correct way to solve the problem would be to better educate the management as well as the programmers. If managers understood what it took to build quality software they might change their view on their development processes.

Educate the programmer, the programmer becomes a manager... voila, you have educated managers.

The programmer only becomes middle management though, they still have executive managers forcing deadlines on them.... My old manager was a former engineer, he tried to battle on our behalf many times, but marketing, product management, and executives just don't understand

You can't make the executives understand... but then they don't need to, because they shouldn't be dictating how the programming is done. They give you a project, the managers explain the project, the programmers do the project. Everyone that has anything to do with the programming should have at some point been programmers themselves. If we start educating our students, it should filter up the career ladder as time goes by.

The problem with management is not lack of education, it's lack of communication.

And the customer meanwhile doesn't like it and moves on to less expensive provider.
I do value the education, of course. I'm just a firm believer that the pressure is also on top of the manager, not only on the programmer. The market itself is unaware of the demands of quality software because it can get results with less.

Fortunately some key areas are protected from this as Bjarne notices. The several scientific fields, certain key government departments and agencies, some specialized software houses, etc. There's where most Programmers are found. But for the rest the state is chaotic and seems to grow like a snowball. For every bad project that sells, for every lower grade programmer that gets hired and delivers... something... the more the rationale will be it works.

Deadlines are dictated by the customer and a proper business man knows not to make promises they can't keep. Besides, do things ever meet deadlines? It's almost not expected, anymore. There is a pretty famous quote by Tom Cargill, that goes something like, “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of development time” ... and personally, I've found this to be more true than bad executives making bad deadlines. Perhaps, along with teaching programming, we should teach better work ethic.

Deadlines are dictated by the customer and a proper business man knows not to make promises they can't keep. Besides, do things ever meet deadlines?

As soon as customers start dictating your deadlines, it's time to move on to a different company. If my company based its deadlines on the wants of the customer, then everything would be due yesterday...

Customers dictate deadlines by maintaining interest and nessesity. In order to keep your customers, you have to make deadlines suitable to what they expect, otherwise you lose them. Just because they don't directly say they want it by the end of the year doesn't mean that by the end of the year they'll start looking for business elsewhere. This is what marketing has to deal with and this is how deadlines are made.

Let's say VB. Someone learns it. What is he going to do with that knowledge? Are there any jobs for VB programmers? And if there are, what is the possibility of getting that job if everyone can learn VB in 5 minutes?