A hierarchy of software engineering discourse
uvwx.github.io
A hierarchy of software engineering discourse
1–10 of 54 posts
Re: A hierarchy of software engineering discourse
#2Very interesting.
I would have treated "requirements" differently - considering them as a mechanism to capture all levels in the hierarchy rather than a distinct level in their own right.
Re: A hierarchy of software engineering discourse
#3> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want.
Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon.
The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger.
On the other hand, when it works, it works. I'd say Rails is an example.
Re: A hierarchy of software engineering discourse
#4Because the linked article inexplicably doesn't link to the Paul Graham article it references, here it is: http://www.paulgraham.com/disagree.html
Re: A hierarchy of software engineering discourse
#5> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.
Usually you have to first build the thing you want and then you can build the thing that will build what you want. You can’t go straight to the second. You need the experience of having built the thing.
Re: A hierarchy of software engineering discourse
#6> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.
Rails is not an example. Rails was extracted from a single project codebase, Basecamp. Extracting a Solution Factory out of the solutions we make is a great idea, but starting with a factory-first mindset is what distracts and then breaks programmers.
Re: A hierarchy of software engineering discourse
#7> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.
>A dangerous fantasy many ships have broke upon.
viz the yet-anothers of: make build system, programming language, configuration syntax, (mvc) framework, ORM, game engine, CMS...
Sourceforge and github are filled with monuments to unrealized dreams and wasted centuries.
Re: A hierarchy of software engineering discourse
#8Most of these levels are actually concerns of different professions, which are today together comprise the art form called programming. For example coding will only become a profession when there will be very restrictive, agreed upon rules ranging from what kind of objects do we have (like service, dto, testcase, etc), how they look like, how they are named, where they are in the source code (with reference to the design of software), what is their maximum complexity, etc.
Remember: a profession is a type of activity which have rules, which minimizes the possibility of mistakes. Which means there are rigid rules, killing creativity.
Re: A hierarchy of software engineering discourse
#9> "1. Fixations... 2. Requirements"
Brilliant!
But I would have condensed the last 3 into one point: "Productivity."
Productivity - accomplishing more with less work - should be the #1 internal goal of every software team. Productivity means you have more hours of the day and more of your effort freed up. This means more time for testing; more time for enhancing your tooling; more time for spikes; more time for upgrades; more time to develop features. Even if no one does anything productive with the freed-up time, it still improves morale and emergency responsiveness.
You can of course go too far with it and ruin your fingerspitzengefühl by automating too much of your work.
Most teams have testers who are built-in advocates for requirements accuracy. But productivity has no built-in advocate. Developers themselves are the first to sabotage their own productivity in pursuit of - let's all just face it - fixations.
Re: A hierarchy of software engineering discourse
#10> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.
The 'notation' level similarly seems to be promoting the use of DSLs, and everything you say here also applies there (maybe I'm jaded, but on more than one occasion, I have had to deal with the consequences of an incomplete DSL that had no real justification, and was clearly developed for egocentric reasons. I have also come across exactly one DSL (not mine) that was both justified and well-done.)
More generally, I agree with the author on the importance of seeing a hierarchy here.