Hacker News Reader

Figuring out the proper abstractions is much, much harder than writing the software itself. Software changes requirements... When you do something new and useful for a customer, they will extend use of the software till it breaks again. You will always run into a new bottleneck.

The proper abstraction is that which can easily be thrown away. I've not found that to be too difficult to figure out. Maybe when I was new to development – that was too long ago to remember – but once you have experience, at least.

It can become extremely difficult to figure out if you mar yourself with someone else's framework. That is quite true. But is also what the parent said.

It's hard to generalize as domains vary greatly, but in general abstractions can account for more than enough extensibility unless the requirements are extremely vague and not well defined. This tends to be the case of why so many changes are constantly needed, because usually Product and Design are not defining requirements with abstractions in mind.

Domain Driven Design basically aimed at tackling this issue, by trying to synchronize abstractions across departments, so I get that there are no easy solutions, especially in large orgs.

Especially in startups clawing there way to MVP release and increasing users/income. Everything is write code to solve specific need now without time to see if it can be better used/implemented. Gotta be first. If we're not first, gotta get traction to overtake first.

Even knowing that and attempting to build something with best principles is still going to be a pain to maintain as it's always a moving target with no proper specs.

There's best principles and then there's over engineering. Business domains can't be properly abstracted when the business itself is in the process of being defined, so if you're the kind of software dev that craves building to a spec that won't ever change, one possibility is that a fast-moving 12-person startup just might not be your cup of tea. Nothing wrong with that, just different.

And if you are the type that does well with band-aid code strung together with duct tape and bailing wire and even bubble gum, then don't get upset when your company gets bought and the entire code base gets rewritten into something that teams can manage

I'm not entirely sure why people who "sling code" would object to their code being completely rewritten -- particularly when the startup mindset is "we'll get something working right now, and once we figure out what we're doing, we can rewrite everything into something stable."

And those who don't want to participate in the "stabilization" effort typically move on to find the next shiny and exciting thing to work on.

Fully agree. People are generally incentivised to solve their domain problems not to develop something that solves theirs - and potentially - problems of their adjacent team. If you can solve for this then you should be encouraging the right behaviour for abstractions which (as others have said) is a hard but worthy problem to spend time on.

Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled.

It's way easier to tell your developers to sprint every two weeks in some random direction, because at least then the business has control. If they were to use the scientific method, the direction would be chosen based on experiments and empirical data that they don't understand or control. Can't have that.

> Well put. I think building software systems can be done with proper engineering techniques. But more often, many businesses don't want that! I've seen some go out of their way to chose technology and processes that eliminate any need for making engineering decisions. The goal is often to "standardize" and explicitly eliminate all novelty. And then they wonder why innovation is stalled.

That's not necessarily bad. The company is derisking by relying on building blocks developed by established companies with deep talent. The vast majority of projects where local developers wrote everything from scratch are nightmarish to maintain, secure and upgrade.

It's not a bad thing if you're doing pure applied technology (IT) work. That should be standardized, there's really no innovation to be had, just optimization. It's when you develop novel products that innovation is required and where rigid standardization becomes a constraint.

Which proper engineering techniques are those?

In general I agree with you, but the devil is in the details and a licensure body is surely the wrong way to do this.

Engineering (IMO) has nothing to do with licensing, and everything with how you approach the problem - Do you use gut feeling to make decisions, or do you follow the scientific method?

In most so called "engineering" orgs, the scientific method is explicitly banned - decisions are made by weird scrum rituals and fabricated storypoint metrics.

Agreed. I think it just comes down to most people being very bad at making decisions and doing stuff. Which, somehow, continues to amaze me given how much humanity has accomplished.

> My perspective is that your typical business does not incentivize, or care to allow their engineers to do "proper" software engineering

Which fields do you think are allowed to do "proper" ________ in a typical business?

If you give me the choice between working with 2 groups of people where one says, "Let's get this done the right way!" and one that says, "Let's get this done!", I'll join the second one every time.

Other engineering disciplines, for one.

And I'm not saying it's perfect, I'm just saying it's done properly.

I think I’ll agree that some licensed fields (medicine, engineering) are more likely than not going to be allowed to do things the “Right Way.”

But at the same time I’d bet if you asked people in those professions they’d likely say, “Our bosses don’t let us do things the proper way.”

It’s more likely everybody thinks they know better than their boss regardless of the field.

I worked as an electrical engineer in the past, and there was definitely a lot of corner cutting, less-than-ideal parts, less-than-ideal suppliers, low-quality materials, and simple day-to-day things at work that just make the life of engineers bad.

But that doesn't mean you throw the baby with the bathwater. I was still liable for things like fire hazard or RF interference, among other things.

Boeing practices would disagree with you.

Boeing was charged with fraud, to the tune of $2.5 billion. Crime and outliers are not a counter-example.

It's not so much that there are wrong engineering techniques as much as engineers being heavily constrained and not allowed to exercise their full expertise. An example of where this is not so much the case would be areas like civil engineering because it has serious consequences if the engineering isn't done right, i.e. a bridge falling. With software there is a lot more room for interpretation as to what engineering really is or should accomplish.

> It's not so much that there are wrong engineering techniques as much as engineers being heavily constrained and not allowed to exercise their full expertise.

What other fields do you believe are not heavily constrained and are allowed to exercise their full expertise at a typical business?

My point is that nearly everybody feels constrained at work because of decisions from higher-ups or whatever. It’s not like software developers are some unique set of people who face challenges nobody else faces.

Part of the challenge is that most developers are not engineers. In proper engineering training, there are best practices and safety guidelines taught across the board by accredited schools. In software any cowboy with a keyboard can produce code. Unsurprisingly, most of it is shite.

I feel like we managed to get much closer to proper engineering in our own little corner: version control, CI/CD, code reviews, don't-write-your-own-crypto, standardization, etc.

The problem is that it's still hard for software engineers to go to business people and say "no, we can't build a bridge that crosses the Atlantic Ocean".

With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth.

> With the introduction of non-technical Product Managers it became even harder. Now we have to convince two layers of people that some idea is unsafe or that it's gonna be more trouble than it's worth.

It speaks again to the lack of rigor in software. In professional engineering practice, the project manager is always a P.E. who takes responsibility for the final design and signs off on the product before it goes out the door.

Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable. The problem today is competitors will iterate with piles of temporary solutions and eat your lunch while you're still designing your abstractions. If they got sued into oblivion for shipping broken crap, they wouldn't be so quick to iterate on junk!

PE licensure could also foster a security culture in software like none other, as no PE is going to put his fortunes on the line to save a buck skipping formal verifications and avoiding inconvenient best practices!

Law may be part of the solution, but overall we need a culture of demanding tailored demos. If you ask an average SaaS, "show me how this can produce value in my environment before I buy in", they may be incredulous and expose that it will take months/years of effort to get it properly integrated.

OTOH there are many genuinely great products that don't require massive upfront effort to start producing value. Demanding tailored demos can help you separate the wheat from the chaff.

> Professional Engineer licensure to be able to actually charge for software (this carves out exception for FOSS and freeware) could raise the costs enough to make this kind of software engineering viable.

You would almost certainly see an increase of in-house software developers and consultants where the code is never charged for, but is developed as it always has been. A few big companies like Microsoft and IBM would get certified and smaller software companies would be driven out of existence entirely.

There would definitely not be a golden age of rigorous software.

I would love for the U.S. to standardize software engineering like electrical engineers. It wouldn't change that much, as most companies would end up switching to "developers", but it would make it clear when a business wants some serious problem solving and not just churning out half-baked features as fast as possible.