[pydry]

In my career Ive seen about 1000 instances of somebody trying to optimize something prematurely.

Usually those people also have a good old whinge about the premature optimization quote being wrong or misinterpreted and general attitudes to software efficiency.

Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

[YZF]

In my career I've seen endless examples of hopelessly badly designed software where no amount of optimization can turn it into anything other than a piece of garbage. Slow, bloated and inefficient.

Ascertain an issue is too late for bad software. The technical term is polishing a turd.

Not that what you're describing doesn't happen, people trying to make something irrelevant fast, but that's not the big problem we face as an industry. The problem is bad software.

[wredcoll]

Hurray, bad software is bad, we did it! Just don't write bad code!

[YZF]

Before you write code you design (and/or architect) a system (formally or informally).

There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

[wredcoll]

Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.

[YZF]

Getting feedback from users for a product is important as well. Those are somewhat orthogonal concepts. I'm not proposing analysis paralysis or no prototyping but I am saying there are some things that if you didn't consider in advance can become huge issues down the road. There are examples (e.g. Facebook or the Google crawler) where very successful products started with something not great and then were able to fix that later but I would argue most of the very successful products and platforms (software or not) have had some non-negligible thinking/planning upfront.

[wredcoll]

I mean, sure, but this becomes kinda circular, "do some planning" "how much?" "the right amount", etc.

I don't think anyone is arguing for zero planning but in terms of very general rules we can talk about on blogs and such, I would definitely advise people to "do more and think less" to paraphrase an old prussian general.

I would say overplanning is a much more common problem but the issues it causes tend to be much less noticeable than the occasional really exciting under planned project.

[Jensson]

> Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

Many things need to be optimized before you can easily profile them, so at this stage its already too late and your software will forever be slow.

[hunterpayne]

"Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path."

That's because your boss will never in a 1000 years hire the type of dev who can do that. And even if you did, there will be team members who will fight those fixes tooth and nail. And yes, I have a very cynical view of some devs but they earned that through some of the pettiest behavior I have ever seen.

[wredcoll]

Man, what are you talking about? Speed optimizations after shipping software happens constantly in everything from video games in C to ui libraries in js and everything in between.

People write some code, test it, ship it, then get some ideas that its too slow and make it faster.

The nice thing about doing it with shipped code is you can actually measure where time is spent insyead of guessing.