Re:My guiding principles after 20 years of programming (2020)
by brodouevencode on Tuesday March 22, 2022 @03:13PM
(#30770201)
Speculative engineering often gets a bad wrap, mostly because people mis-characterize it. For example: a feature is written up for a product that talks to X third party system. The same organization has other teams using X system. Wouldn't it be wise to abstract that integration work out to allow other teams to use it instead of building their own, especially in the agile world where teams are highly autonomous? This is often characterized as speculative engineering, when in fact it's engineering for scale.
If you do not offer the possibility to learn to your employees they will try to learn while working on a project which is where problems come from : speculative programming or hype-driven-development.