Is there any merit to fighting code bloat in today's PC age?

[yoda291]

It depends really. If you're doing web programming in a scripting language like php or perl, I can tell you with near absolute certainty that your first priority is coding quickly over efficient and fast code. get a working page up asap because, in a business enterprise, the administration will prolly not give two sniffs about code efficiency or streamlining. They just want a working edition done now (or 5 minutes ago). Indeed, it's my experience that 80% of all administrators don't know much about computers beyond HTML or "Hello World"...and they shouldn't. They're business people, not techies.

With C or C++ coding for software, it's prolly better to have properly documented and well-written code because buggy software that sees a release date will cost you in sales. Also, efficient code can run on more computers, giving you a larger user base. It's code based on making money where, if you lose sales because your code runs slow or crashes or has a memory leak, you lose $$. If your code works perfectly, but runs so inefficiently that it REQUIRES state of the art technology, you lost $$.

I guess in the end, it's all about the $$

 

[Anubis]

ANTI-BLOAT!!!!

all teh way

 

[KevinMU1]

Good point about expandability and updatability. Those are key... although sometimes it's hard to have the vision to see what you might need to add in the future. A bit of a chicken and egg problem, if you will.

I guess another question I would ask is--even if something is well-written, if it's not useful, is that bloat? Like what about the 90% of the features you don't use in Word? Maybe they're coded well, but if you don't use them, are they bloat too?

 

[stonecold3169]

depends on what you're doing. If you are releasing a commercial product, keep in mind that optimizing code takes something very important :TIME. Now, there are cases when optimization matters a whole lot, such as in an OS or in large scale databases with frequent usage and what not... but in many cases you are right, there isn't a real need for it.

Well, although now that I think about it... I have a pretty nice rig, and the time it takes winamp3 to open an mpeg or divx file is obscene compared to WMP (I think I just called WMP optimized code ). Granted, by obscene I'm talking maybe 5 seconds with wmp versus 10 with winamp. But it FEELS much different. I guess we don't need it. Although, optimized code helps us advance software faster at an earlier date.

 

[FeathersMcGraw]

Originally posted by: KevinMU1
OK, so one of my tenets as a developer has been keeping software trim, being minimalistic, and trying to keep code sizes down with various optimizations and rogue programming techniques. I guess it comes from my old days on the Commodore.

Here's my question: does anyone care anymore about code bloat and multi-meg programs that seem to be able to do far less than the size that they take up would imply? Is there any merit to writing tight code and keeping file sizes down? It seems anymore that in the age of huge hard drives, broadband, and fast processors, that compact, efficient code just isn't worth the time anymore.

Am I fighting a losing battle with no merit, or does anyone out there still hold on to these old virtues with me?

While knowing how to optimize at a low level is useful in low-resource environments (embedded), it can be a serious detriment when trying to write cross-architecture platform code. It may also have scalability impacts on future development (remember, Y2K was a resource optimization bug).

Knowing how to write low-level optimizations is a tool that should belong in every programmer's toolbox. However, just because you have a big hammer, does not mean that every problem is a nail.

 

[Odoacer]

it's like some dude mentioned above... these days, maybe SIZE doesn't matter as much as SPEED. So I'd take a big program that's fast as opposed to a streamlined program that's slow. While yes, readabiity is imporant, it's just a matter of commenting out your code (something that can be done right from the outset) and naming your variables and stuff beyond the scope of "int x".

And reusability, i think that's a different ballgame... if you want to make a versatile class that can be used through 20 different programs then i'd say you're going to have to make sacrifices on both fronts.

 

[Descartes]

The perception of bloat is highly relative. I differentiate between two forms of bloat: functional, and implementation. Lets first consider what constitutes functional bloat:

Any functionality that is ancillary to the user(s) scenario.

And of course implementation bloat:

Any egregious violation of basic principles of reuse (DRY - don't repeat yourself, OAOO - once and only once, and orthogonality)

I always found it highly humorous that users of a system were somehow able to discern a state of implementation bloat for a given system. If you use 5% of an application's functionality, then obviously it will appear functionally bloated.

Implementation bloat is entirely different. A user is unable to discern a state of implementation bloat. Implementation bloat is a side-effect only; a manifestation of principle violations. If you have 5 developers each writing classes for a given use case, and each developer has their own class which implements common behavior, there's a chance this common behavior can be refactored into a common class serving all developers. If this doesn't happen, the side-effect is implementation bloat. This happens quite a bit in Dilbert-Principle-enforcing environments with a single code monkey to a cubicle. They often only release their code when they are finished, producing the big bang of code bloat. This is obviously a very basic example, but it helps demonstrate the core issue. This is why I am in strong favor of agile methodologies; they promote constant refactoring, continuous integration, etc., that help preempt implementation bloat.

The above is really at a higher, perhaps architectural, level. There is less chance of bloat with most languages today simply due to orthogonality. This is in stark contrast with languages like Perl, a language with TMTOWTDI (there's more than one way to do it) as a major tenet. In languages like Java, C#, and in a lot of cases, C++, there is little indirection between the conceptualization and implementation process. If two developers are given requirements for a class in these languages, there's a strong chance that both implementations will be very similar. Conversely, if you give the same requirements to two different Perl programmers, chances are they hugely different. This "freedom" of implementation allows for greater chance of implementation bloat.

Ok, I lost focus. Hopefully I was lucid enough to make my point

 

[KevinMU1]

I never realized how many different perceptions there are of bloat... I envisioned first when I made this post about size of executable/data files bloat... that is, Visual Studio.NET taking 2 gigs of hard drive space, for example. To me, I'm not getting 2 gigs worth of product there. I don't see HOW it can possibly take that much. And that's just one example.

There are always tradeoffs when programming, and the trick is, as mentioned, finding that delicate balance of factors--reusability, modularity, speed, size, etc. And it does depend on the application. I guess in today's age I'm kinda big on small file sizes, just seems absurd that we are lugging around these huge files. Sure, we CAN because we have the space, but that's not really adequate justification in my mind.

I hope we can get a few more poll votes. It has been absolutely fascinating... I never imagined so many people would care about bloat. But, at the same time, it's easy to say, and what does that support really mean? How far would you go? If Word was offered with only 10% of its feature, the essential 10%, would you use it? Or would you keep hauling around the full one, just in case? There's some psychology here, methinks. Anyone have any ideas on how attached people are to some forms of bloat?

 

[KevinMU1]

bump

 

[skace]

I wouldn't consider hard drive space a real problem. I would consider memory usage / memory leaks / speed / optimization a much much huger problem these days. Far too many programs come out with memory leaks or that just arn't optimized to run very well.

 

[slpaulson]

Originally posted by: KevinMU1
So those of you using ICQ, how do you justify that?

I use the Miranda client =)

 

[KevinMU1]

Could it not be argued that bloat contributes to leaks and code being not optimized?