5 ms·

I almost hate to say it, but the answer to your last question might lie in instituting the kind of standards, credentialing, mentorship and licensing that exist

I almost hate to say it, but the answer to your last question might lie in instituting the kind of standards, credentialing, mentorship and licensing that exist in the "real" engineering fields. Stuff that will correctly be called out as unfortunately really "hampering individual freedom" (including the freedom to be a jackass) and being "unnecessary" and "bureaucratic" and (quite intentionally and without quotation marks) gatekeeping. Civil engineering is sort of the oldest and ultimate example, where a bad design puts people's lives at risk. In deference to said lives, senior engineers in that field review every drawing or calculation that goes out the door, and they also mentor the junior engineers, who have to be graduates of accredited schools, and also can't get certified until they've spent a certain amount of time being mentored and passed the exams, etc. The mindset you're talking about is basically all about craftsmanship or elegance of a solution. Formal mentorship or apprenticeship programs do a great job of maintaining and transmitting that. School isn't really enough, and certain fields have recognized that fact. In software however, and I'm not sure whether this is the problem or the symptom, the number of developers apparently (I was told recently) doubles approximately every 5 years. Which means the field is always overwhelmed with new people, full of energy but not experience, who want to do something cool and exciting, but haven't been, for example, burned by their own past decisions to try to do something cool and exciting. They see only upside. Which is valuable in itself, but they need more direction than they're getting, from the older engineers who have the war stories and who aren't especially concerned with being cool (which c'mon let's face it, is essentially a mating display) and who are boring.

dkarl 6y ago
I think traditional engineering standards would enable over-engineering rather than discouraging it. In fact, I think engineering standards would be every architecture astronaut's dream, because it would be an excuse to architect every small company's software to handle Netflix load. "This is an X type problem, and the standard says the data for X type problems has to be stored in a distributed event log." We would have to flip the standards on their head and write them to say, you are not allowed to use Kafka until you have a problem meeting certain requirements. Projections from our sales pipeline say we can only use technologies certified for less than ten requests per second. Can you imagine a bureaucratic oversight committee rejecting a CQRS design with streaming everything and telling an engineer, "Seriously, WTF. This is a config console. It will have less than 300 users two years from now even if you live up to that insane hockey stick graph they showed the investors. Just build a basic CRUD app backed by RDS. Use the same front and back end frameworks you use for everything else. The engineering standard says you can't afford to waste time on this because there's a lot of other work you're going to need to do this year, and some of it might turn out to be hard, even if you don't know what it is yet." Can you imagine that? Math and physics also have a strong cultural orientation towards simplicity, which seems to be universally embraced. If you solve a homework problem in half a page, and the professor calls on somebody else to put their proof on the board, and they walk up with two pages covered front and back, you don't think, "Wow, they're smart. Their solution is so much more complicated; it must be better." Conversely, if you and all your friends took three pages to solve a problem, and somebody else presents a solution that fits on one chalkboard, you're in awe. I really don't know what the difference is that makes the culture of software different. I think if it's being enforced by standards or licensure, it's too late and too external. It needs to be internal and cultural, at a gut level, to aspire to do more with less. In software, the primary measure of cost, the definition of "less" in "do more with less," is the intellectual load on the software development team. (We have that in common with mathematics.) Do more with dumber. How do we learn to value that as a profession?

dkarl 6y ago

I think traditional engineering standards would enable over-engineering rather than discouraging it. In fact, I think engineering standards would be every architecture astronaut's dream, because it would be an excuse to architect every small company's software to handle Netflix load. "This is an X type problem, and the standard says the data for X type problems has to be stored in a distributed event log." We would have to flip the standards on their head and write them to say, you are not allowed to use Kafka until you have a problem meeting certain requirements. Projections from our sales pipeline say we can only use technologies certified for less than ten requests per second. Can you imagine a bureaucratic oversight committee rejecting a CQRS design with streaming everything and telling an engineer, "Seriously, WTF. This is a config console. It will have less than 300 users two years from now even if you live up to that insane hockey stick graph they showed the investors. Just build a basic CRUD app backed by RDS. Use the same front and back end frameworks you use for everything else. The engineering standard says you can't afford to waste time on this because there's a lot of other work you're going to need to do this year, and some of it might turn out to be hard, even if you don't know what it is yet." Can you imagine that? Math and physics also have a strong cultural orientation towards simplicity, which seems to be universally embraced. If you solve a homework problem in half a page, and the professor calls on somebody else to put their proof on the board, and they walk up with two pages covered front and back, you don't think, "Wow, they're smart. Their solution is so much more complicated; it must be better." Conversely, if you and all your friends took three pages to solve a problem, and somebody else presents a solution that fits on one chalkboard, you're in awe. I really don't know what the difference is that makes the culture of software different. I think if it's being enforced by standards or licensure, it's too late and too external. It needs to be internal and cultural, at a gut level, to aspire to do more with less. In software, the primary measure of cost, the definition of "less" in "do more with less," is the intellectual load on the software development team. (We have that in common with mathematics.) Do more with dumber. How do we learn to value that as a profession?