Hazel Weakly
I find it fascinating that we talk about over engineering as if it's a thing in software engineering. It's not, cut it out, stop talking about that.
If I'm a contractor and I over engineer something, guess what? It works for that use case and all the future ones. The only thing I wasted was money and time. Did you make a 10 ton capacity deck when you only need 2 tons? Cool... It's still a deck.
Software engineering? We don't have over engineering. We have "building to solve the wrong problem"
Marly Puckett
@hazelweakly for the same reason naming things is the hardest problem in computer science, understanding business needs is extremely hard and the only thing that actually matters at the end of the day. You can always google "how to balance a binary tree" you can't Google "wtf does this Product Manager what from me?!?"
Marly Puckett
@hazelweakly while doing consulting it was incredibly obvious that the most valuable (aka "stickiest") service we could provide was a translation service from business needs to technical requirements. Talking to users is by far the most important skill you can have.
Hazel Weakly
The secret to software engineering is to focus all of your energy as a team (and a company) on learning how to share information between each other better. Build that understanding. Build that ability to uplift and teach each other.
For fuck's sake, stop worrying about over engineering and worry about under understanding the problem.
The over engineering goes away the second you start putting humans first and start prioritizing understanding over an artificial roadmap built without context
Hazel Weakly
But over engineering? In software? It's not a thing. "yagni" might be a thing, but it's also still addressing the wrong part of the problem.
If the hardest part of software engineering is building mutual understanding among a group of humans with different contexts, backgrounds, and approaches, then it stands to reason that trying to anticipate future problems will result in *solving the wrong problem*
We don't over engineer, we just build the wrong thing.
Hazel Weakly
It sounds ridiculous when I phrase it that way, but I see things that are that obviously incorrect all the time. A huge problem is that software engineering is so incredibly abstract, ill defined, and nebulous, that it's non trivial to even find out that you're building a deck at all, much less what the load capacity should be.
Software engineering is hard because there's no rules and no answers and it requires mutual understanding among groups to an extent that rivals the Tower of Babel
Hazel Weakly
In software we don't build a 10 ton deck when a 2 ton deck would do, we build a Deck Builder Factory that prints out decks that are fully extensible up and down but we build it into a concrete foundation where the only extension options are sideways. Then we bolt on safety join points to the house that prevent you from actually extending the deck at all. Then we only use the printing system once and throw it away. Then we complain that we over engineered the deck. But the deck? Rated for one ton
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.