Comment by thibauts | Hacker News Reader

Comment by thibauts | Hacker News Reader

Parent Full thread

Another silver bullet in the making.

I don't mean to be rude but to me it's pure BS. A grand plan, a conclusion talking about paradigm shifts, and no substance at all. Seeing the method co-signed by Robert Martin even made me chuckle a little. I guess we're on for a second round.

This is clearly meant for management (again) and doesn't give a hint of a clue to what is the practice of software engineering.

Won't they ever understand (I use they on purpose as they're clearly not us) that software engineering is the process of discovering and documenting in a formal language the methods to be applied to solve a problem defined in an ambiguous natural language with the use of imprecise concepts. What we really do is assess the validity and feasibility of what an user wants, and along the way refit concepts, articulate them in a way that can actually work or formally make sense. Building software is the act of understanding how the implicit things we take for granted are actually not. This is a discovery process. This precludes precise estimates or estimates at all, which is very difficult to finally accept and live with, I concur. It has to be dealt with in most cases or in a large part like a research endeavour.

We'll have some day to take things at face value and learn to live with them.

Your comment is actually one of the best formulations of software engineering I've ever read. However, I'd disagree, at least to some extent, with your conclusion:

"This precludes precise estimates or estimates at all..."

While we software developers do occasionally solve novel problems that can't be estimated since the methods for implementing them are not currently known (i.e., research problems), most of the problems we work on are variants of problems we've already solved, and our experience - especially if we record it and make an effort to learn from it - can be used to estimate the scope and complexity of a project (including the "discovery process").

Sure, sometimes our estimates will be way off, but an estimate that's within a factor of two or five of the actual cost of a project is more useful than no estimate at all.

The people who are paying us (management, customers, investors, etc.) will eventually want to know what they're going to get for their money and when they're going to get it - and sometimes the answers to those questions need to be answered before they provide any funding at all, since a solution might be completely useless to a customer if it's not available by a certain date.

I should have worded it "This precludes precise estimates and sometimes estimates at all", as of course depending on your knowledge of the problem domain and your field experience you can get some degree of confidence.

Software Engineering is in a way meta engineering discipline. Problem domains are vastly different. A mobile game development is different than building a system software for surgical robot. The first step is to define the vocabulary of the solution space and then build the solution based on that vocabulary. Expectations of reliability, maintenance, requirement changes adds another dimension to its solution space.

The best way I've heard this described is this:

Engineering has a well-defined constant you're always building against: gravity.

In software, you choose your gravity, and it changes all the time. Sometimes there are twelve gravities. Sometimes there are different types, and they interact in complex unpredictable ways.

In short, it is a much more difficult problem. But personally I believe we can reach a meta-engineering capable of achieving quality in a predictable way.

Engineering is not as simple as building against gravity. There are a lot many things that "engineers" (non-software) have to take account of, even in something as mundane as laying out a road. In this example, you not only have to build the road within the area; you have to build it so that it has the right curvature so that vehicles can make the turn etc. You have to make sure that the road you're laying out has a solid base; you need to make sure that the road can withstand the natural forces of that region for whatever time it is designed to last against. So I don't understand how engineers build against gravity.

But if you're saying that engineering has to follow the laws of physics, then yes, I'm totally on board. Computer Science departments in most universities started of as branches within the mathematics department. While most of software engineering is more than simple math; it does operate on its own plane, with no regard for the laws of physics (except maybe of time :) ).

In that regards, Software Engineering seems more of an art, doesn't it? But it does have its own guidelines; which govern how good software is written.

A road is a bad example. The only reason a road is required is because of gravity.

I disagree with your hand wave of "software = art". Software is also bound by many constraints. Time (as you mentioned) is not trivial because it's the difference between useless and useful software. Memory also puts limitations in that can't be ignored.

Useful software runs on real machines bound by physics. Theoretical computer science can disregard the constraints to see what's possible, but that's CS and not SE.

Software engineering is an art in that it's more like theory building than theory using. Each project, each context is its own set of new physical laws.

This is the point, yes.

Software is not all made up out of thin air -- you do not 'choose your own gravity'. The equivalent of phyical laws in software are computational/algorithmical, logical laws.

For example, sorting cannot be done faster than O(n log n) -- that is as hard and objective as anything physical. (In fact, one would think it is even harder in some sense, since it is so purely logical.). Software is built within algorithmic constraints.

Only comparison-based sorting is bound by O(n log n). Non-comparison based sorts can do better.

>What we really do is assess the validity and feasibility of what an user wants

Then why do software developers get no training in talking to users? In understanding them and make sense of what they tell us and what they really?

This to me is the biggest short coming of today's software 'engineering'

Reply on news.ycombinator.com