4 ms·

> 1. Make it work 2. Make it good 3. Make it fast Disagree. The first two objective clashes very much with each other. I have worked in teams that did that. An

> 1. Make it work 2. Make it good 3. Make it fast Disagree. The first two objective clashes very much with each other. I have worked in teams that did that. And generally if anything non trivial is done without planning to just "make it work", it would be more often than not, ridden with many design issues which doesn't allow it to be good.

ActorNightly 4y ago
If you start designing into the future, you are now trying to make it good before making it work. Making it work means you start with barebones, just to have a proof of concept that runs, is accessible, is secured, even if you have to click things together and manually ssh into EC2s to launch code. Once you have everything working, then the bigger design should be a lot clearer, in terms of what you have to do to make it good.
nerdix 4y ago
I've never seen anything that couldn't be incrementally improved. There are definitely tons of situations where the additional effort to "make it good" is worth incurring upfront. But you can definitely make something work then make it better. And a lot of times, you'll find that your carefully planned out "good" solution ends up not being all that good and needs incremental improvement. It can be hard to get something right on the first try especially if you haven't done it before.
- jakupovic 4y ago
  Fully agree here. Not being abe to incrementally improve something that works would be a contradiction as the original thing never worked at all then.
- rektide 4y ago
  I see way more making-poor-decisions underbidding-complexity, then spending years hacking on shit cause it's kind of jank. When folks have license to do good work, I usually see it going well. If they have some informed opinions & group wisdom at their disposal & which they leverage.
- YetAnotherNick 4y ago
  I have rarely seen bad but barely workable website become good with incremental improvement. After the product reaches some threshold of users, it is hard to change the code structure in a safe testable way if there is no good way to test it in production like environment, and so developers are rightfully afraid to make any big changes in one go. I have seen many examples both internally and externally. - My bank's website which is a decade old and has millions of users, has tons of issues. I am not even talking about UI or look. It randomly hangs, session disconnects etc. - ERP tool of one of my previous org sucked, even though used by 10s of 1000s of people and having dedicated team in maintaining. - One team that I worked with has no proper staging environment, and it would have required synced deployment of dozens of services with many teams working with different language and config. And just this simple task couldn't be completed even with push from upper management, just because of complexity. Lot of companies doesn't even have these: Have a way to properly test product, have actionable alerting/logging, have reproducible environment, and distribute ownership clearly among code components. Kubernetes more or less forces a reproducible environment.

ActorNightly 4y ago

If you start designing into the future, you are now trying to make it good before making it work. Making it work means you start with barebones, just to have a proof of concept that runs, is accessible, is secured, even if you have to click things together and manually ssh into EC2s to launch code. Once you have everything working, then the bigger design should be a lot clearer, in terms of what you have to do to make it good.

nerdix 4y ago

I've never seen anything that couldn't be incrementally improved. There are definitely tons of situations where the additional effort to "make it good" is worth incurring upfront. But you can definitely make something work then make it better. And a lot of times, you'll find that your carefully planned out "good" solution ends up not being all that good and needs incremental improvement. It can be hard to get something right on the first try especially if you haven't done it before.

jakupovic 4y ago
Fully agree here. Not being abe to incrementally improve something that works would be a contradiction as the original thing never worked at all then.
rektide 4y ago
I see way more making-poor-decisions underbidding-complexity, then spending years hacking on shit cause it's kind of jank. When folks have license to do good work, I usually see it going well. If they have some informed opinions & group wisdom at their disposal & which they leverage.
YetAnotherNick 4y ago
I have rarely seen bad but barely workable website become good with incremental improvement. After the product reaches some threshold of users, it is hard to change the code structure in a safe testable way if there is no good way to test it in production like environment, and so developers are rightfully afraid to make any big changes in one go. I have seen many examples both internally and externally. - My bank's website which is a decade old and has millions of users, has tons of issues. I am not even talking about UI or look. It randomly hangs, session disconnects etc. - ERP tool of one of my previous org sucked, even though used by 10s of 1000s of people and having dedicated team in maintaining. - One team that I worked with has no proper staging environment, and it would have required synced deployment of dozens of services with many teams working with different language and config. And just this simple task couldn't be completed even with push from upper management, just because of complexity. Lot of companies doesn't even have these: Have a way to properly test product, have actionable alerting/logging, have reproducible environment, and distribute ownership clearly among code components. Kubernetes more or less forces a reproducible environment.