Software engineering is about working with different layers of abstraction | Hacker News Reader

Software engineering is about working with different layers of abstraction

4 pointsitsmefaz7 comments

One of the things that my mentors or industry veterans have failed to teach is the importance of abstraction.

I've been in this industry for few years and being self-taught one of the questions that still disturbs me is what the goal of software engineering was about?

My mentors (typically principal or staff engineers) would answer it along the lines of the business use case. And for some reason, I'm not satisfied with the answers or maybe I'm just too arrogant to accept that the business matters more than its engineering discipline.

It just occurred to me today that the most difficult part of software engineering was building better abstractions. And the issue I had comprehending was not the business aspect of it but the actual definition of software engineers (and software engineering). I guess the better definition would be 'system designers' or even 'abstraction designers' because that is what we always do build complex systems for simple components.

Maybe I'm just naive in my thinking?

I would say instead software is just communicating, and communicating is about abstraction. That's from the user to the CEO all the way down to the software/hardware.

There's a shift from communicating in an imperative manner to communicating in a declarative manner. Even between humans, communicating to a junior/senior, there's a difference between how much imperative and how much declarative communication you do.

Business use case is very declarative - "This app should send me a reminder before my appointment."

The next level of abstraction breaks it down further: How many minutes before the appointment? How many reminders? Email, push notification, in-app? Which of these are practical given our resources?

Then the next levels break it down further. Do you want more control (imperative) or do you want more abstraction? Is it so dumb you have to explain to it step-by-step how to thread itself and clean up memory?

And then there's a different level where you have to explain it to the other person maintaining the same code.

Sorry for the delayed response. This is interesting! I was thinking similar but more than just communication. I'm currently of the mindset that at a fundamental layer, engineering is more a human nature problem - understanding humans and helping them in completing a given task.

Engineering is the applying of science and technology for practical use, as far as I'm concerned.

Consider electrical engineering, and getting AC power to your computer. There are huge systems sometimes spanning continents, that then fan out to smaller and smaller branches, then to your home or office. Each and every section of that network was protected with some form of fuse or circuit breaker. They are all coordinated in such a way that the smallest breaker in the system will trip first if there is a fault on it's part of the network. At the end is a circuit that delivers a standard voltage at 5-20 amps, at 50/60 Hz, depending on your country. The circuit will protect the wiring in the walls against overcurrent, and will sometimes, depending on local regulations, even protect against flow through you, and arcing in the wires.

All of the systems were fairly rigidly engineered to prevent issues, even when struck by lightning, attacked by rodents, cars, or the odd tree. Everything that makes up the system is engineered to a set of specifications.

Contrast this with software engineering. Right now, it is not a strict engineering profession.

There is no equivalent of any of the above in the world of computing. You have a computer that can flow all of its resources (and YOUR resources) into any task, no matter how wrong it is, with no provisions for limiting side effects.

We've got a LONG way to go in the world of software. Like the early days of electricity, there is a strong tendency to blame the user when things go wrong. And there is a strong tendency for things to break, due to lack of safety factors.

The way we distribute computing resources, our operating systems, are not fit for purpose. When you run a task, there are no circuit breakers of any kind.

Now, when you consider all of that, is fixing that part of your job? No, it is not. However, being aware of the bigger issues, and perhaps seeking solutions in the off times, might be.

The thing you are hired to do is to solve business problems, but in a way that is not going to risk unnecessary harm. If there is something that might bring down the business, it is your responsibility to report it. If there is something that may endanger people, it is your responsibility to stop it from happening.

Computing is a tool in service of business. The computer is just a tool, not the goal.

Sorry this is a bit of a rant, I'll be glad to clarify any questions.

Very sound argument.

Software faces additional challenge of being similar to agricultural monocultures in parts - unlinked systems with same code can all fail at once because, say, a date bug hits.

Thanks for your response, Mike.

Maybe I'm thinking about computing as an end itself and just too insecure to acknowledge its application aspect. Because it seems to me that when the application becomes the end-goal then the engineering loses its value.

Can't find the source, I think it was a link on HN. What it said was basically "software engineering is programming over time". To me this also means read "reuse is hard". So _one_ application is not engineering, but all useful applications over time would be. =;-)

When I was young, I had to have the latest version of everything, this was long before the security aspect of it. The problem with that approach is the random disruptions it creates when you focus on the tool, and not the task.

You'll see stories all the time about machine shops with MS-DOS programs still in use, for example. But consider the facts, a problem was solved, that solution has worked consistently for decades, any new solution is likely to create problems, so of course it's going to stay around forever. Just don't hook it to the internet, and it will be fine. 8)

Once a business need is met, you just want to keep the friction as low as possible.

Reply on news.ycombinator.com