5 ms·
_All I'm saying is you can build a pretty successful business even with a bad engineering team._ I completely agree. The most important lesson I’ve learned in
by yoz 7y ago
_All I'm saying is you can build a pretty successful business even with a bad engineering team._
I completely agree. The most important lesson I’ve learned in the past decade of software development is:
Good product/UX design can save bad engineering, but it doesn’t work the other way around.
- endymi0n 7y ago100% this. Tackling a real problem > Having a big addressable market > Good product / UX > Great Engineering. Strictly. Great Engineering pays back at a much larger time scale and makes for an enabler or a breaker at the critical scaling stage only. You can get surprisingly far with a protoduction service and still build something huge (see Twitter). Great design is atomic and homogenous. Weak technology leadership ends up in opening up a vacuum that gets filled by Architecture Astronauts (Etsy), every team doing their own thing technologywise (SoundCloud), or at the very worst, some dogmatic homebrew NIH stack (various places I‘ve worked at). Every unhealty Technology organization looks unhealthy in its own way, but the great ones look all alike: Clean, simple, rather homogenous and logical.
- StreamBright 7y agoThis is only true with boundaries around engineering quality. There can be not so great engineering making it impossible for the business to be successful because their solution is more expensive than the revenue generated.
- bpicolo 7y agoDepends on the type of software. If you're building transactional software where your business is doing a few bucks cut per user transaction, the software can be tremendously bad before it hits into revenue, as long as you’re not totally busting the user experience
- m0zg 7y ago>> can save bad engineering Depends on how "bad". I've seen _many_ counterexamples, where no amount of lipstick could fix the underlying flaws. What good is a pretty website if it's slow, or if it doesn't work at all half the time.
- Aeolun 7y agoI see this fixed all the time by throwing more resources at it. Case in point, all servers were configured to accept a maximum of 5 connections, so when the load balancer got more than x concurrent requests, they started failing. Instead of fixing the problem, we can just scale the amount of servers (horizontal scalable yay), until the problem goes away. Now you have tons of 8GB/4C machines sitting (almost) idle, and immense amount of money wasted.
- AlchemistCamp 7y ago> Instead of fixing the problem, we can just scale the amount of servers (horizontal scalable yay), until the problem goes away. This works if the bad engineering causes a linear increase in scaling costs. If the bad engineering causes an N! increase or a 2^N increase in scaling requirements, then there's a good chance all the servers on the planet aren't enough. I'd say engineering is no easier to fix by throwing money at it than UX is.
- the-rc 7y agoUntil you eventually run out of connections on the DB... And all the workarounds that ensue.
- Aeolun 7y agoDon’t worry, we have a REST service for that too!
- conradfr 7y agoLet's say software is "data -> code -> UI". The two most important things are data and UI, the one thing we developers spend all of our time thinking and talking about is code :)
- mtbcoder 7y agoThere are plenty of successful applications with bad UIs. Also, business logic is encapsulated in code - if that's borked, no amount of UI will save it.
- masklinn 7y ago> There are plenty of successful applications with bad UIs. Because data >>> UI >> code. > Also, business logic is encapsulated in code - if that's borked, no amount of UI will save it. The assumption here is that the bare minimums are fulfilled. If the software doesn't work at all you have none of the above.