4 ms·
At least from my view this is a shift towards actual engineering culture. You'd never see a civil engineer or most any other engineer operate under the "move fa
by jacoblambda 5y ago
At least from my view this is a shift towards actual engineering culture. You'd never see a civil engineer or most any other engineer operate under the "move fast and break things" philosophy.
Making prototypes and experimenting is one thing but something I consistently see with the "move fast and break things" philosophy is that production is your prototype. Sure things may go through testing first but at the end of the day features get pushed out to prod once they have an MVP and are iterated on and beta tested more or less live.
I'd love to see SWEs be more willing to sit down, make a prototype, and toss the entire thing away taking the lessons learned to build the real thing rather than trying to build the actual product off the bat or trying to send the prototype straight to production.
All this extra review and rigour is a good thing for anything going to production. The real problem is that we don't build our prototypes outside of production any more. Build your prototype on your own fast and loose but anything that actually gets near the master branch should be inspected and picked apart to the highest of standards.
- im3w1l 5y agoWe were in a gold rush. No point building a boom town to last. With the gold rush coming to an end people want quality again. Actually it makes me wonder if startups will stop being a thing too.
- ByteJockey 5y ago> You'd never see a civil engineer or most any other engineer operate under the "move fast and break things" philosophy. Because people will die. Software engineers who, say, work in the airline industry don't do this either (they also probably use ada or something like it). I'd also be willing to bet a significant amount of money that an engineer that works on something like soft drink bottles moves a lot faster than one who designs bridges.
- XorNot 5y agoExactly: there's no one true way, there's just the acceptable tradeoffs. Which is the proposal I tend to write the most when businesses send a requirement my way: "X is important. Ensure X." - whatever X is, you can usually then pretty quickly outline how to do X perfectly, and how much X will cost, and suddenly there's an acceptable degree of X (which is usually outlandishly far below the implied standard of the original request) because as it turns out, they simply didn't think X had any real cost associated with it.