Often overlooked, the core tenet of engineering is public safety. This is why professional engineers are required to obtain a license, register in their practicing jurisdiction, and are held liable if their work fails to achieve a prescribed consensus of acceptability.
Imagine if software was held to the same level of scrutiny..? Software is carpentered, some is designed, and little is actually engineered.
Engineers don't fail forward, early, fast, or often. They don't move fast and break things. Not engineering software is great, because if you had to pull permits to build your software, the web would still look like 1996 and my phone would have a keypad.
I have always treated my professional work with software as very serious business.
We aren't developing anything with direct life-safety consequences, but we are dealing with PII and other people's money. I see no reason to relax due diligence on anywhere along this spectrum. It's either correct or its not, and the consequences for getting something wrong are universally bad for all involved.
Now, I also strongly believe in the idea that software development is inherently an art form. The nuance is that within this art form, there are still very rigid conceptual frameworks you need to work with. For instance, designing the UI for any application is more-or-less a pure art form. Developing the SQL schema backing that UI is arguably something that is 100% deterministic and can have mathematical proofs established which prove its correctness one way or another.
The key to the success of any software project is blending these two worlds together in a sustainable and responsible way.
> Developing the SQL schema backing that UI is arguably something that is 100% deterministic and can have mathematical proofs established which prove its correctness one way or another.
Maybe I'm misinterpreting your point here, but the way you create the different models, compose the modules which will use them and represent the abstract entities and processes that execute when that UI is interacted with can be done in many ways, both well and very badly, depending on the measurements you take to evaluate it.
All the different terms to consider 'clean', 'maintainable', 'readable', etc. code, I consider to also be somewhat abstract to define in an art-type of way.
The reason I mention this is that the 'visual design' of the UI is not so much a software work as much as a UI/UX designer work. Bringing that design to life in an application using actual code and not a design tool is where the same principles I mentioned above come into play, even if the actual 'visual design' was completed by a different person which might not code, or the same dev.
I would argue that there is a very specific form of normalization that any problem domain should be modeled in - 3NF or BCNF. This is a universal idea because of how it allows for relational algebra to easily produce any higher-order functions over the dataset. Poorly-normalized data is where all of the code & SQL spaghetti originates. These forms of normalization can be specifically tested for and validated.
If you get a super clean domain model in 3NF, you can be assured that writing business logic on top of this will be a breeze. Getting relationships between domain types incorrect, or having facts on the wrong types, is how you get a vicious cycle complexity layering on top of itself as you try to compensate for bad foundations.
One thing that burns a lot of developers is the need for circular dependencies. You cannot say that circular dependencies are disallowed when trying to model the real world. An example in banking would be Accounts can have many Customers related to them, and Customers can have many Accounts related to them. Attempting to "choose sides" on this is folly. The most correct path is to create 3 collections - Customers, Accounts, and AccountCustomers (or CustomerAccounts). Getting this one thing correct can save you years of developer hours on the bigger projects.
If you are using something like .NET, you can abuse LINQ to produce any arbitrary projection you desire in a few lines of code. If you want your business people to have a hand, you can expose SQL as a scripting language against your properly-modeled domain. There are so many good reasons to slow down and pay attention to what you are calling things (and what boxes you put the things in).
To put it more briefly - The argument I am essentially trying to make above is that there is actually one truly correct way to model a specific problem domain and you can test for many degrees of that correctness. I will admit it is never absolute, but I feel it gets damn close if you are thorough in applying single responsibility principle to the logical business facts.
> Developing the SQL schema backing that UI is arguably something that is 100% deterministic and can have mathematical proofs established which prove its correctness one way or another.
Maybe you can prove what software does, but "proving" that what it does is the right thing is necessarily subjective and grounded in reality; mathematical proofs need to get dirty.
This is my pet peeve with many software developers. They develope software like a photo lab technician develops a roll of film: Let's see what result we get now, if it is problematic move to the next thing.
I think bot good engineering and good desin practise is the opposite of developing a picture. It is really iterative process, trying to factor in as many of the important aspects as possible and try to get the one solution where all of these aspects don't fight each other, but strengthen each other.
Many software developers I met are just focused at what framework/language/design pattern/etc they are going to throw at the next problem. Of course that is all exiting, but what if the thing you are tackeling could be solved so much better, if you just killed your darlings and tried to find the best solution?
Sure you cannot learn $framework you were curious about on the way, but finding elegant and good solutions is itself a skill that needs training.
The projects I have been involved with tend to have high level design discussions at the beginning. Working in a team has that as a necessity, otherwise we can't figure out how to partition the work of actually building the software. Yes, we figure out what data structures we need to use at a high level and then grow the code incrementally to tie it all together after that. But maybe that's fallout from working mostly in the system / embedded / network protocol space for most of my career where frameworks are not really a consideration.
I wonder where this notion comes from that you can not fail fast in engineering. Both science and engineering are all about fail fast and fail often or even all the time. This is the base tenet of both engineering and science. FAIL. A lot.
There was an essay that I saw on HN where the author talked to a bunch of "real" engineers -- i think the author had some 'real' engineering experience and software engineering experience -- to try and compare and contrast and see if the things people usually say about the differences are true.
I can't find it now! Which is frustrating me. Anyone else seeing htis have any ideas?
It was enlightening, and challenged some things we assume about differences. "real" engineering is also pretty diverse, of course, not just civil engineers making bridges and highways.
> Imagine if software was held to the same level of scrutiny..? Software is carpentered, some is designed, and little is actually engineered.
This is why I never approve criminalizing software bugs.
Imagine if you committed some codes, then turnout codes in that commit can be exploited by hacker 10 years later, are you willing to be imprisoned for creating codes that "fails to achieve a prescribed consensus of acceptability" ?
Imagine if software was held to the same level of scrutiny..? Software is carpentered, some is designed, and little is actually engineered.
Engineers don't fail forward, early, fast, or often. They don't move fast and break things. Not engineering software is great, because if you had to pull permits to build your software, the web would still look like 1996 and my phone would have a keypad.