3 ms·

From a business point of view, performance and reliability (and code quality) are irrelevant. The most important thing is that the product has a market to explo

From a business point of view, performance and reliability (and code quality) are irrelevant. The most important thing is that the product has a market to explore. We can see this in many products. I've been working with software since 1999, I've never seen any developer or manager worry about performance. I've seen a religious battle over formatting or using a Java library, or "it's not the Ruby way". I never participated in any performance or reliability meetings, or projects, or religious battles. In general, performance is only fixed in very extreme cases. For example, I worked on fixing code that generated a few megabytes of SQL. Or code that uses all of the server's memory. And it's hard to get permission to fix some extreme bugs. The code that generates a million stored procedures after a few months still exists at one of the places where I worked. At another company, I fixed a problem (infinite printing) that had been around for 20 years (I even made a birthday cake for the bug), under pressure from the biggest customer who couldn't use a report and no workarounds worked anymore. 20 years of workarounds. You are sometimes seen as a radical if you try to fix the most absurd bugs. Today I document the bug and wait for the prioritization. Sometimes you fix it after 20 years...

pixl97 4y ago
I agree. Typically when it comes to UI issues features and being first to market tend to win over speed. Simply put the slowness of the average human interacting with the software is a much larger factor then the software itself. Of course this is also to a point. 1 second versus 10 seconds to do a major software operation isn't going to affect most users. Now stretch that out to 100 seconds and priorities start changing. You get in the 'really annoying to people' zone. I think one of the differences when looking at performance is how many times it is executed. I might pull up some customer record/ticket in SAP 50 times a day. If its 1 second or 10 seconds doesn't matter that much because I can generally interweave it with other operations I'm performing. Now, if for some reason I was executing that a million time a day, like a single database query, suddenly we're talking about an issue that's worth fixing.

pixl97 4y ago

I agree. Typically when it comes to UI issues features and being first to market tend to win over speed. Simply put the slowness of the average human interacting with the software is a much larger factor then the software itself. Of course this is also to a point. 1 second versus 10 seconds to do a major software operation isn't going to affect most users. Now stretch that out to 100 seconds and priorities start changing. You get in the 'really annoying to people' zone. I think one of the differences when looking at performance is how many times it is executed. I might pull up some customer record/ticket in SAP 50 times a day. If its 1 second or 10 seconds doesn't matter that much because I can generally interweave it with other operations I'm performing. Now, if for some reason I was executing that a million time a day, like a single database query, suddenly we're talking about an issue that's worth fixing.