Comment by flueedo | Hacker News Reader

Comment by flueedo | Hacker News Reader

Parent Full thread

Yeah but being a translator is a different kind of activity from being an engineer, architect or craftsman. It feels to me that being a Software Engineer -- though currently I've been working with something else -- is kinda like (grossly simplifying it) a really complicated game of Lego or Tetris, where the 'pieces' (APIs, routines, functions, protocols, legacy code, etc, etc) don't always fit where/how they were supposed to, sometimes you can tweak them, but sometimes they're black boxes. Sometimes you have to build some pieces, after giving up on trying to make do with what you got. I think that's what the OP means by time wasted. We waste a lot of time getting the pieces to fit and (as much as we can verify) work as they should when we should be spending our time focusing on what structure we want built after all the pieces are in place.

Engineers, architects and craftsmen don't work, nor waste anywhere near as much time, with as many "pieces" (if any) that behave in such erratic ways.

As the son of an architect, I must somewhat dispute this characterization. There are tremendous constraints in that craft which are sometimes parallel to those of software development.

Budget is the first constraint, which limits the available materials and determines material quality.

Components and building codes are a second. While the 'fun' part of building design might be the exteriors and arrangements, a tremendous amount of the effort goes into binding these 'physical APIs' in a standards-complaint manner.

Finally, there is physics. This brings with it the ultimate and unassailable set of constraints.

I know I'm being a bit silly, but my point is that all crafts have frustrations and constraints, and all professions have a high (and often hidden) tedium factor resulting from imperfect starting conditions. These do not actually constrain their ability to create works of physical, intellectual or aesthetic transcendency.

I agree. I felt like this within my first month of working professionally in 2001 and ever since.

Thank you for the apt metaphor. I often struggle with explaining how I feel about this but you nailed it.

We spend too much time getting these tiny pieces to connect correctly, and more often than not they're misaligned slightly or in ways we can't see yet (until it blows up). It's way too much micro for not enough macro. And there isn't even a way to "sketch" as I can with drawing - you know, loosely define the shape of something before starting to fill in with the details. I keep trying to think of a visual way to "sketch" a program so that it would at least mock-run at first, and then I could fill in the function definitions. I don't mean TDD.

One way to partially do this ,by using an auto generation as far as possible. Naked objects(for complex business software) takes this to the extreme - given a set of domain objects, it creates the rest, including GUI. Than if for example, you want to customize the GUI ,you can.

I think it even makes sense at start to create uncomplete objects, run the mock, as continue. Also, the authors of the framework claim that you work very close to the domain language s you can discuss code with domain experts, so in a sense you're working relatively close to the spec level.

The learning curve is a bit high though, i think it could have been much more successful if it has used GUI tools to design domain objects and maybe a higher level language,

Sorry, but UML provides enough definition to accurately describe any process... you generally need two graphs for any interaction though. Most people don't think in these terms. Some can keep it in their heads, others cannot.

It's easier for most people to reason about a simple task. Not everyone can also see how that simple task will interact with the larger whole. I've seen plenty of developers afraid to introduce something as fundamental as a message queue, which is external to a core application. It breaks away from what they can conceptualize in a standing application.

Different people have differing abilities, talent and skills regarding thought and structure. Less than one percent of developers are above average through most of a "full stack" for any given application of medium to high complexity (percent pulled out of my rear). It doesn't mean the rest can't contribute. But it does mean you need to orchestrate work in ways that best utilize those you have available.

> Sorry, but UML provides enough definition to accurately describe any process...

Which is the opposite of sketching, which means (in drawing) to loosely define the basic shapes of something before accurately describing things with "enough definition".

We're not talking about the same thing at all and I can't relate to the rest of your post.

I'm talking about how there's no way to sketch a program that mock-runs and then fill in the details in a piecemeal fashion.

Reply on news.ycombinator.com