Posted on 12/17/2001 4:33:52 AM PST by damnlimey
coupled by inadequate supervision/management of those responsible for 'systems' of their own programming staff and accompanied by...
They got a lot of these straight out of college types running things from where I am sitting. Many of these guys don't know their *ss from a whole in the ground. Lots of engineer types in charge too. I dunno. A lot of these guys have never written a shred of commercial quality code.
inadequate programming standards (such as permitting no documentation, no modular thinking, no shared libraries/resources)...
We are affected by the lack of documentation. Big companies have an entire documentation department. A large phone company that we with worth comes to mind. Their product is buggy and inferior in many ways, however. They have so many analysts this, program managers that, and other managers over there that sometimes I wonder who actually does the work When your at a smaller shop docuemntation suffers though. Good programmers should self document. In the code.
rush deadlines agreed to by managers causing their programming staff to have to take short cuts and either produce inadequate documentation or eliminate documentation;
Hahaha...Hey! You been spying on my company?
The operating environment as in the 'shop itself'. For example, high programmer turnover and its impact on somebody having to go behind and decode spaghetti.
This usually cannot be helped. Lord knows I and everyone here has cleaned up so much spaghetti..
Good points. Not sure if all of these things are more responsible for bloat then the advent of rapid application development languages.
Bingo! You win a prize!
Yep. Well said.
Thanks. I'm in diagnostics research and quality troubleshooting. IOW, I'm a professional pessimist.
I won that prize back in 1986. My brother was in a EE class and was supposed to write software for a microcontroller that would display letters on an LCD screen. He had all the bits that would turn on the segments of the display and needed to write the code that would translate ASCII into the segments. He was having trouble, so he called me.
I told him to make an indexed table using the ASCII - 'a' as the index value and put the word in the table that would cause the LCD to display the letter that matched the ASCII value. I told him that, if he worked for me, I would like a solution that took several K bytes of memory per system over a system that took him days to write and test because hardware is cheap and I could build the price of the memory into the system. I couldn't recover his time in the same fashon.
The instructor used his result to demonstrate good engineering to the class.
Shalom.
Argee does hit it on the mark with programmer costs vs. cheaper hardware.
And, as you said, "rapid application development languages certainly makes it easy to churn out code"
Perhaps it's not that Bloatware is the problem - provided two things, that the Bloatware performs as advertised AND you have the cpu cycles to spare (as ctdonath2 noted).
But, if you unfortunately purchased or have had to maintain Crapware, then that Crapware is often Bloatware.....
But usability has been improved. At least that's what they tell me to say.
HA!
Have you seen the requirements for installing Linux?
Linux ISN'T immune to this 'phenomenon' either ...
True, and I would argue that it's better to err on the side of caution. Look at how widely Code Red was able to spread because people had no idea that their Windows machines had a web server running. If a user gets to the point where he needs advanced functionality, he should be sufficiently competent to enable it himself.
I know you're a coder - but I did not blame the individual developer or coder.
As a matter of fact, what I wrote was that it begins with the 'instruction', however that 'developer' obtained the instruction:
I wrote:
It has everything to do with Programming Design or the lack of it. This lack is a result of:
If you are not taught to code properly; if the manager/supervisor does not instruct you otherwise; if you manage to sell your code and people don't complain or have no alternative, you will continue to code poorly, and, perhaps, heavens forbid, churn out Crapware and Bloatware.
You did say software bloat is a complex issue - I agree - but for a different reason: because we have not defined it precisely.
"My favourite is 'writing hard core C to create slick tight code'."
-- Bill Gates
That's not a good example at all! The "bloat" you see there is so that the programmer doesn't need a Master's degree and ability to do this:
title Hello World Program (hello.asm)
; This program displays "Hello, World!"
dosseg
.model small
.stack 100h
.data
hello_message db 'Hello, World!',0dh,0ah,'$'
.code
main proc
mov ax,@data
mov ds,ax
mov ah,9
mov dx,offset hello_message
int 21h
mov ax,4C00h
int 21h
main endp
end main
And can, instead, do this:
#include < iostream.h >
int main () {
cout << "Hello, World!" << endl;
return 0;
}
"I would have written a shorter letter but didn't have time." -- Blaise Pascal (1623 - 1662).
Simple question, simple answer: The reason for all the bloatware, is because Programmers will link & compile entire libraries of code into their application, even if they're only using one or two functions from that library.
Much of this article struck a chord with me. My first programming job out of college was with a financial services company, that specialized in car dealership management software. The first version of the entire application ran on a single 1.2mb floppy - and that included months worth of sales and service records. Granted, this was back in 1987.
In 1990 when I left, the code was up to 3mb to run, with a months sales taking up another 3mb. As we added functionality, our function libraries got bigger and bigger. When we switched programming tools, our code base tripled, simply from the nature of the compiler, and the necessary re-write of the code to utilize NEW function libraries.
This article makes perfect sense, the author is spot on. The tools to create the applications are hogs. The libraries required to write code and add functionality are hogs. Programmers (self included) are hogs because we're lazy. We'll gladly link in that entire function library to get the ONE function we need. As long as we don't have to write it from scratch, it's fine by us.
That's the ONLY reason necessary and sufficient. That hardware costs less than programmer time is immaterial. In fact I've worked on projects where that wasn't true, yet bloat still occurs.
As long as someone will pay on an invoice, anything can happen.
The far better question is this:
Why do the people who pay prefer Bloatware?Time after time bloatware wins the market battle. Why?
And in most cases this is a good thing to do. Every line of code you don't write is a line that won't have a bug. I'll gladly use libraries that reduce the amount of code I have to write, even if the resulting program is bigger. I'll work faster, and users will get better reliability.
Unfortunately, too often today programs seem to be bigger *and* buggier, so linking libraries may not be the culprit there.
You should have made it multiple choice. Can I provide the choices?
a. Bloatware is inherently superior to properly sized software.
b. People who write bloatware have more time to spend developing marketing hype.
c. Evil, unlawful, monopolistic practices.
d. People are idiots.
Shalom.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.