3 ms·

> Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qu

> Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qualitative though often quantitative) insight into potential, cost, and complexity. The problem tends to be in getting that feedback back into "the room where it happens", the place where budgets are set, approvals are given, disputes are resolved, and performance is evaluated. In that room, there is usually a heavier presence by people who understand organizations, political concerns, messaging, and revenues. So when the cost and risk experts (the devs) are not in the room, of course we end up with overly complex, poorly understood products that chug along for a while and then become so massive that either: a. the project collapses under its own weight b. the project creates its own "gravitational pull" and starts pulling in resources to support itself; sometimes this is locked-in customers who cannot migrate away, sometimes this is locked-in enterprises who can't imagine how (and sometimes why) to kill it off

DrScump 9y ago
In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common priorities are: 1) nearness to midfield ("What yardline are my seats nearest?") 2) sun exposure ("Will I be baking in the sun all day? Do I need sunscreen? Will I be looking into the sun when trying to watch play on the field for a portion of the game?") 3) home vs. visitor side 4) elevation ("Am I low enough to see the players? Am I high enough to not be obscured by bench and media personnel?") If you're designing the site/app and you've never been to a (an American) football game, you won't know these criteria are important.
- humanrebar 9y ago
  Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided. Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company. Profit and success doesn't happen until both sides of the story are accounted for.

DrScump 9y ago

In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common priorities are: 1) nearness to midfield ("What yardline are my seats nearest?") 2) sun exposure ("Will I be baking in the sun all day? Do I need sunscreen? Will I be looking into the sun when trying to watch play on the field for a portion of the game?") 3) home vs. visitor side 4) elevation ("Am I low enough to see the players? Am I high enough to not be obscured by bench and media personnel?") If you're designing the site/app and you've never been to a (an American) football game, you won't know these criteria are important.

humanrebar 9y ago
Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided. Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company. Profit and success doesn't happen until both sides of the story are accounted for.