I remember when I first realized that software companies had a fundamental problem with how they handled finished products. BulletProof FTP. It was a magnificent FTP client decades ago. I used it on my dialup connection to practice data hoarding. I paid for it because it was a trustworthy companion in my adventures through the net. But, that turned out to be its ownfall. It was feature-complete and it was excellent (although they never did fix the problem with quick reconnects resulting in a pre-existing binary transfer socket getting picked up for use as the command connection, spamming the thing with random binary data and confusing the hell out of itself and the user...). But clearly, that was unacceptable. They continued to shoehorn in irrelevant crap that nobody wanted. Eventually it got so bad that it wasn't even very good at being an FTP client any more. I've since seen that repeated innumerable times since. A product is completed, but people still have to be kept busy with fake work that destroys everything they built. The fact we still use the structures and ideas designed for factories and assembly lines for modern companies is ludicrous.

As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization. This is an inappropriate motive in the management of a system design activity. Once the organization exists, of course, it will be used. Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

See also iTunes, the Mac version, iTunes for Windows has always been shit.

It will be interesting to see if the SaaS subscription/rental model changes this. Or if they feel as beholden to adding features each release as people trying to sell software releases to get upgrade income.

I think the rental model will slow this down, but not get rid of it entirely: not as long as people still want to write blogs about the "new version of our product". I think JetBrains will make a good case study: their products are feature complete and they seemed to struggle to find new features to add lately (plus they have switched to rental model).

What we really need is something similar to API versioning: when GMail has a new version, bump up the version to 24, but keep version 23 accessible to those who prefer it.

What Jetbrains MUST do: improve the performance! Replacing my MBPs spinning rust disk with a SSD helped, but it's still eating up CPU when running on battery with indexing... it's a text editor for fucks sake.

Keep in mind that JetBrains IDEs started not as a text editor, but as a rename utility.

So really, it's closer to an AST tool with text-editing features.

Editor is definitely the core but all the support tools make a big chunk of features and usage. Sure, I can get quite a lot of those features in Sublime with some packages but they aren't that well integrated and easy to use!

That said, consider Microsoft Word. Since forever, it's been doing similar - if not greater - amount of work processing and reprocessing text every keystroke than IDEs contemporary to it. Yet somehow, it is not bloated, it does - and always did - work well on even low-tier machines. Also compare with OpenOffice, which does more-less the same things, only much slower and buggier. If M$ can keep Word functional and performant, I'm pretty sure Eclipse and IntelliJ could be made fast as well.

P.S. as someone who has commit access to LibreOffice (and much to everyone else's chagrin, sometimes uses it), I could be a little bit biased.

OTOH, all Java IDEs I've used so far lag by default. It's often about the little things - like those 1 second delays in menus, or 100ms delays between keystroke and letter appearing on screen, etc. Enough to make the experience frustrating. If I keep using them it's only because some advanced features don't have an equivalent (or easily installable equivalent) in Emacs. But it's a tradeoff between having a powerfool tool that I use every once in a while vs. enduring the constant experience of bloat.

Features of IDEs are cool, but they seriously need to optimize them. And to stop assuming that every developer gets to work on a brand-new machine. Maybe it's true in the US, but it's not true in other places (sometimes because managers don't see a problem with paying developers $lot but then being cheap on the equipment those same developers have to work on).

I personally use LibreOffice quite a bit, but something about the name sounds silly to me, so I avoid speaking it. I usually refer generically to "a word processor" instead.

For the software creator, once you've sold someone your software, the only way to make more money is to sell it to someone else, or create and sell a new version. Eventually you run out of someone-elses to sell to and can make new versions or go out of business.

... or sell a support contract or a subscription model.

I don't like it from a user's point of view, but squaring my preferences as a user with preferences of business isn't easy.

Maybe one day we'll reach the times when programming is done by "programmer-archaeologists", as described by Vernor Vinge in "A Fire Upon the Deep", whose job is to dig through centuries of legacy code covering just about any conceivable need, to find the snippets they need and glue them together. But right now, software gets obsolete just as fast as physical products.

In practice, yes, most things we buy are designed to fail. But in principle 30 years is possible, if anyone is willing to pay for it. Lots of people aren't, for many reasons including time cost of money, fashion, or just not caring.

> Most software has to be replaced after at most 10-15 years, either because of security issues or just because it's no longer supported by hardware.

Yes, so there's the answer for why the software upgrade treadmill exists: it's for software not important enough to run on dedicated separated hardware. Few people are upgrading CNC controllers or power plant controllers or aeroplane controllers because of security issues or because the hardware is no longer available.

Anyway, even on the consumer side the lifespans are rapidly lengthening. In the 1990s running current software on five-year-old computers or using a five-year-old OS would have been basically unheard of in the mainstream. Today a five-year-old computer is only a step behind current and Windows 7 has turned 6 years old and is still extremely widely used.

My mom is still using a cooking stove she bought in 1982, as a second hand purchase. Parts of it have been repaired/replaced, but I don't think they make em like they used to: I doubt a 2016 stove will make it to 2049.

It's not that creating more durable products is significantly more expensive (it could, and was done in the 80s), its that manufacturers cut costs of manufacturing and their B.o.M. in the interest of maximising profit.

[0]: https://en.wikipedia.org/wiki/Software_rot

The "rot" is because the environment is changing (the hardware you're running it on, other software you need to interact with) or the software is being carelessly updated.

If you need to, software rot can be eliminated. It takes effort but it can be done.

To give an example: you can run a space station with software installed in the 1980s, but you probably can't run a space station with seals or pumps installed in the 1980s.

But then again, there's a paradox: if they do nothing and someone shows up that, for some reason, steals their customers, they can get in trouble, like Orkut fell and was "replaced" by Facebook. If they do something that breaks the experience, they can loose users to another player (recently in Brazil, WhatsApp was banned for 48 hours and lots of users signed up for Telegram. It wasn't WhatsApp's fault, yes, but it's just one more showing of how easily users migrate when they're not pleased).

So what do you do? You have to be careful with where you take your service. But standing still is just waiting for someone to come and stab you.

I thought Hacker News and Reddit handled that. :

One methodology that I employ is "visibility-based development" where we will save up some super easy tasks that may have a big visual impact. When we need a sprint or two to get some boring clean-up work done, we'll throw in a few of those easy tasks with it. We've had some releases that look like a big, major release but in reality we only spent 1/2 a day on the features that seem big. The rest of the time was under the hood cleanup.

In some cases it's not simply your customers that require the illusion, but the management team as well. If you have a management team that gets uneasy if they don't see new features happening with every release, I highly recommend using this technique.

Heck, that goes for most of Google. Look at this beauty: https://www.google.com/?noj=1&gws_rd=ssl Why is this not still the default google.com?

By the way, why on earth would anyone want an app to do a google search? When searching for a webpage, the best 'app' is going to be the one that shows webpages, named 'the browser'. It's like going to weightwatchers.com and seeing a banner ad that tells you "it's better with mcdonalds". It is laughably grotesque. What happened to google that they've strayed so far from sanity?

Because it provides a neat search widget, plus Google Now.

There is a "basic" version (which they also advise against) which is significantly better, but still slow and bloated. Yahoo used to be my go-to account back from around 1997, but after the successive iterations of bloat, it's now in a point where I only use it for unimportant website registrations (i.e. spam fodder).

It's not about creating vs. removing "stuff". It's about value and advancing business objectives.

That's to say that your citation doesn't carry weak perception b/c it mentions removing stuff, but rather b/c it fails to mention the value that created. A better way of wording it might be something like:

"improved [site performance, or dev efficiency, or something else] by XYZ% by removing low-use features, without sacrificing revenue or customer satisfaction."

... b/c simply removing features (regardless of LOC) used by 10% of a user base, in and of itself, doesn't offer any justification or value. I'm not saying it can't, just that I'd be concerned if that happened without strong rationale and a measurable net positive.

And the same goes for adding or building stuff. E.g. If you wrote a project management system at your previous job, focus on citing the number of hours or projects it tracked, or how it reduced the number of meetings required. The fact that you "built" it isn't as interesting as the value it created for the team/company.

So if positive perception is what you're after, focus on presenting measured value. Then, whether it was created by adding or removing is a non-issue.

Managers are rewarded and promoted based on everything they & their team "do", not on what they "undo" or "don't do"

So manager x adds 10 things to the website, gets rewarded and moves on, then their replacement adds 10 more things, gets rewarded and moves on etc.

It's in the interests of those managers future careers they don't allow anyone to remove the things that were added during their reign, otherwise the list of things they "did" won't be very impressive.

I honestly think that a lot of companies should seriously re-evaluate how they function. Once a product is perfected, the developers should probably be switched over to being paid "on retainer", so that they continue to get paid but do not have to go into work constantly and maintain a 40 hour work week. Let them work from home, and just require them to be reachable. When maintenance is needed, ping them to do it.

Case in point - my dad's kettle, the push button to open the lid broke. The tiny plastic lever in the internals that was the ultimate problem had been moulded with material from the pivot removed. There's no way it wasn't designed to fail within a short time period. Add back that plastic or otherwise reinforce that pivot and it would likely work for several more years.

Another example, microwaves: I bought two new, [admittedly] relatively bottom end, microwaves consecutively. Both appeared to fail due to the cyclotron, neither part was available to buy. So instead I got my parent's old microwave from the 1980s. It really pained me to get rid of those new shiny stainless steel boxes, made so attractive to the eye, in favour of the beige-and-brown monstrosity with the working internals.

I have seen this happen at least twice in the past: start with a great team, smart people, self-sufficient. New manager comes in. What does the manager do? Stay by and watch the team do what they do best. Nope, start to set up meetings to improve communication, to streamline, to optimize, adds new rules , new Kanbans, some agile thing maybe, intensify devops a bit. "But why? it doesn't make sensse". Developers are wondering, watching their motivation and productivity get sucked out.

But it does make sense. The manager has a manager. When the end of the year comes, they'll have to report "I did X, implemented Y, facilitated Z etc". They are paid more than the average developer, their know it, the expectations are high. They have to do those things, so that behavior starts to make more sense.

Add to this people leave, new people come in and day what the old people did they could do better. A couple years later new people discover why the old people created what they did.

New people either look for new jobs or get into the same cycle as the ones before them.

http://www.chesterton.org/taking-a-fence-down/

Good managers remove things when they serve no purpose (prevent extraneous development), when they aren't being used (reduce technical burden / debt) because they look at the data, and the changes they make are tied directly to the success of the business.

This assumes a bit of a functional work environment, but if you aren't inside of one, the problem you are dealing with isn't bloated webpages, its bad management.

I would add that modern broadcast news has always relied on other types of imagery to break up the anchor shot, chiefly prerecorded reports from the field (which do not require a truck -- at my station the photographers and reporters used ordinary cars) and weather screens. The SNG trucks are nice to have when something big does break, but most of the time they are simply not needed ... hence the contrived uses and excuses.

I think the sharp decline in costs for competing technologies are forcing a rethink of newsgathering costs. In recent years, helicopters have been replaced by in-studio CGI based on traffic maps and (on occasion) drones. This trend will accelerate, although I think one of the main expenses -- "talent" -- won't go away. Viewers do like personalities and on-screen charisma.

There's absolutely nothing wrong with considering a change, deciding it isn't a gain for your users, and then NOT doing it. It may not be a glamorous call, it may not be a resume item, but that's real product management right there.

There is probably no way they'd end the year with "Yap, site worked great, we did a nice job 2 years ago, so I didn't touch it this year."

They should take a page from Toyota's book and have 10 separate teams with projects for Gmail's next version. Except, instead of evaluating with metrics, reduce to just 3 options and expose the next versions as public betas and take measurements on how well people like them.

The business reality is when a feature is added, there's almost no way to remove it, because the result would be less money to pay salaries. Hopefully the benefit would result in more than 10% of additional sales with better features and changes.

I certainly would not say that we "strive" to make any feature go away. In some cases, though, a certain feature can actually prevent us from implementing new functionality. It's always a tough decision. We don't want to leave any customers behind, but at the same time we don't want a small minority of customers preventing us from moving forward either.

I don't think these kind of decisions should be left up to a lone developer to make on their own. The developers, sales, support, management and everybody should be working together to understand our customers and what our mission is. It's not easy.

It was just an example.

> what if removing that feature means that 10% of users who use it are no longer paying customers?

I can think of scenarios where that feature for 10% of customers is causing issues for rest 90% of customers, or eating up all the support time or ops teams' time.

> The business reality is when a feature is added, there's almost no way to remove it,

Even code-wise. Once a framework is adopted, it is hard to rip it out to make things lean again without making a fundamental change.

Google has a "VP of Design" now, and the one commonality of his tenure has been massively increased page load times, and buttons moving to different places regularly for no apparent reason.

If you can't get a 70-year-old to understand what you're asking them to do, you're wrong.

I have "appraised transport policy to reduce the number of agency drivers employed, projected saving $50k annually with no loss of service" rather than "used linear optimisation of transport schedule in Excel".

I have the opposite opinion. If you're applying for a job with me and have something about cutting 10k lines of crap then you've got my attention.

Being able to recognize when to delete code is a very valuable and underrated skill.

So you end up with the designers, developers, content editors, SEOs, managers and clients all wanting different things at once, and none of them want to remove what's already there to lighten the load.

Because micro-managers lack technical competence, they 'shop' for solutions. They have to buy into advertising claims from SaaS companies that will perform wonders all for a small, per-transaction fee.

Why use the reviews feature that came with the CMS system when you can just add some third party thing for doing the reviews? One simple script and a tag, job is done, Disqus is on the site and any problems with the reviews then becomes something 'supported' by Disqus. No developer of the front end variety is needed to theme up the reviews that came with the CMS. Megabytes of stuff gets added instead of a few lines of CSS and the text content of the reviews.

Need a slider/banner thing for the homepage? Forget the actual requirements for a small selection of images that click through to somewhere else with normal hyperlinks. Instead pay for some bloat, only $70 a year, chicken feed! Let the developers struggle to get this behemoth working and ignore their protestations that animating a simple carousel is not 'rocket surgery'.

That pesky search box at the top of the page... Why use the built in CMS search augmented by a few simple site specific rules to fix the things not found? Instead of doing that, go to some 3rd party SaaS app that cripples the server downloading stuff from one index to put in another, far, far away index. The SaaS service will do everything and better than what the in-house fixes will deliver, the advertising says so and they have pie charts to prove it.

Those stupid social network icons. Again, let's Add This and see if it will float with those lead balloons added. It make perfect sense to add thirty scripts to the page just in case someone needs a 'Tweet' button.

Usually these inept decisions are made in good faith by a manager who does not know what he/she is doing. But they have managed these sorts of projects before, right?

Those bloat items usually do have a knock on effect of implementation difficulty. But, by then, these 'agreed on' features have been paid for, approved by the client and handed down from on high by some micro-manager.

I have never met a developer that goes with the bloat out of choice, they just know that a job is just a job with a paycheck. Their little bit of the project, e.g. 'frontend' has no concern for page load time, they just have to implement designs handed down to them by some micro-manager that has got some other person that can't code to do some pretty pictures in Photoshop. It is paint by numbers for the 'frontend' guy, performance is not their thing. Same with the backend guy working on that API integration for pulling through those 'tweets'... Again, no responsibility for page load time, for their work is in the backend, not how the site renders.

Another layer of people that can't code gets added with the UX guy. They might get only as far as designing the pages the Photoshop newbie has to 'draw', adding 'lorem ipsum' text accordingly. Yet these UX guys never seem to roll up their sleeves and optimise the stack for a speedier UX experience. No, why do that when you can go to meetings and conferences to learn how other people do these things?

Then there is the outside SEO agency. Let's face it, the people in SEO didn't do degrees in anything involving difficult things like programming or science. Yet these guys want another dozen scripts added to the page so they can measure how their 'campaigns' are going. More bloat signed off by a middle manager.

Too often the figures that matter (sales) are far from accurate or completely missing from the SEO agency reports. All the numbers that matter are all there in the server logs and the sales order tables should they bother to check, but why do that when you can pay for yet another analytics SaaS? Who cares if a percentage of the site visitors use 'ad block' of some sorts, rendering all efforts at this type of frontend stats scraping useless.

Newsletters. Who is for a newsletter? Again, how hard can it be to send an email? Not that hard, add an SPF record, get the to and from bits correct and that is it, good to go. But no, only idiots do that, what you need is to pay a SaaS a small fortune per email sent and wow, again pretty pie graphs deep-stalking the readers. More bloat with yet more customer data shuffled across the internets.

This point about newsletters is a backend thing rather than page bloat however it is typical micro-manager FUD thinking. Everyone knows it is a nightmare running your own mailserver, everyone knows that it takes one customer to mark one email as spam once to make all future emails effectively go into a big spam filter forever more, never to be seen again. With this being the case, best pay $0.02 per email to some SaaS to 'do it properly'.

No micro-manager knows that a 'send only' server works pretty well with next to no configuration, that SPF record still has to be setup if using 'monkeychimp 360' or whatever and that these 'tracking benefits' are not beneficial at all except in theoretical edge cases. (All they do is remove limited focus away from the numbers that really matter and stop common sense being used).

Then there is the spamification of emails - does that really happen if not using the SaaS service? Find out first then move to the 'Saas' when one's server gets blacklisted for spewing out spam-tastic-click-bait? That would be the cost effective choice, but no, let's just rely on a third party service for something as basic as sending an email!!!

Helpless micro-managers, the same ones that 'never got fired for buying IBM' a generation ago are the culprits in small to medium sized enterprises. These guys can't code. And code IS important, it is not just something you get a programming resource to do. (okay it is).

These clueless micro-managers can't have confidence in their team to deliver because they have no confidence in themselves to do anything actually difficult, i.e. needing a textbook to learn or fundamentals to grasp. Consequently they are forever being less than cost effective buying cheap bloat instead of engineering something better.

The bloat add-ons are also bloated up to appeal to the micro-manager mindset. That homepage slider, let's sell a slider that does all those tacky DVE dissolves that television was cursed with in the 1980s!!! Rather than the simple transition people know, let's have 200 effects to choose from! So micro-manager buys the 200 effects slider because it is 'better'. Forget that only one effect was needed, go with bloat and don't step back and think for a moment that a banner slider can be done by mere mortals using things like hand-written code. Why reinvent the wheel when you can have two hundred on one of those caterpillar tracked things they used to have to move the Space Shuttle to the launch pad. We're enterprise too, right?

I don't believe there is a coder in the world that goes for bloat, unless they are useless. I also believe that coders go with whatever the team decides, i.e. what the micro-manager hands down from on high. They suffer the bloat to make others happy, a pragmatic thing and certainly not to get a 'bonus'.

  - Load all if jQuery when we just need a few functions
  - Load all of Bootstrap when we just need a grid system
  - Load a whole templating library for one little widget ("we'll need more later")
  - Load a whole icon don't when we're only using two of them
  - Load a whiz bang carousel library when we only need to roatate a few images
  - Use prefab themes that do all of these things and more (shudder, *parallax*) with the idea of providing nontechnical users with the ability to do anything they can imagine without learning to code a little bit

Or SaaS websites that have a single-page web app with a 4MB JS file. And their user interface looks like designed by an committee. The single page web app has a long loading time, looking with DevTools it turned out it's a GWT+Ember ugly monster, that was slapped onto their old rusty Eclipse based Java product. The little information they can show is shown on a 7-times nested navigation page structure so they can advertise it as "drill down" whereas competitors show all info on a maximum of 2-3 times nested pages, and most info is visible without a single click. And the bad one is very much into enterprise with a huge sales stuff, the better competitor is a SaaS-only company.

Developers cost a lot of money. Mailchimp doesn't. Maybe your "clueless micro-managers" know a little more than you think.

This would weight code refactors with the weight they deserve...

Optimized website. Improved loading time by .3 seconds on average for all users. Created cleaner and more efficient design and implementation. Etc...

Well, those 10% would probably be pretty pissed off if you did that...

> "Or the bubble is going to burst. [...] we need to ban third-party tracking, and third party ad targeting. Ads would become dumb again, and be served from the website they appear on."

It's already insane that many news well know websites load 25+ third party trackers with 4+MB of waste. All these poor battery powered devices have already a hard time.

I hope to see less of this in 2016.

Happy New Year!

I implemented this in 740 bytes uncompressed.