> 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.

> "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.

Seems like the spirit of this article is "don't debate test coverage, code design, etc. and just get the job done because meeting requirements is all that matters" and that we should focus on making code shorter. No evidence is offered that shorter code is somehow better than code that adheres to "best practices" or has higher test coverage. Has anyone here fit an entire enterprise software system into half a page, thereby obviating the need for unit tests and clean, understandable code?

This feels like someone that just wants to throw whatever code they want over the wall without being bothered to design it well, write tests for it, and adhere to a team's shared design guidelines. I can't stand working with people like this. Just my two cents.

EDIT: I see that this isn't the primary point of the article, and that maybe the author means we could rid ourselves of so much debate by creating more powerful tools and working at a higher level of abstraction. I think that some of these same things are being attempted, though, when someone suggests a design pattern or something within existing code that could raise the level of abstraction, and that it's worthwhile to have that debate rather than label code design best practices as trivialities.

The idea of "notation" falling into this hierarchy is really fascinating to me. Typically, if starting a new project, I will select a language from those that I am already familiar with based on my comfort in the language and the performance characteristics of the problem.

The idea of the language you're using to solve the problem being one of the things you're developing is an exciting and scary thought. Exciting because you can immediately implement any ideas you have into the new language, scary because stack overflow won't save you if you paint yourself into a corner.

In modern times, I can think of two languages that seem to have been built to provide solutions in specific problem domains: Go and Jai. Go is a fantastic language in certain problem domains, and I wish I had more excuses to use it. Jai isn't available publicly yet, but the creator of the language builds games for a living, has built (and shipped) multiple successful games, and he's building the language so that games can unchain themselves from C++.

I believe the article of the linked article is correct that this should be part of more engineers' toolkits. It may feel like it's easier to just use keep using C++ (or whatever) but what feels easy now doesn't protect you from the inevitable problems of the future.

Because the linked article inexplicably doesn't link to the Paul Graham article it references, here it is: http://www.paulgraham.com/disagree.html

I think that "code style, naming conventions, source code and repository layout" being commented on by younger devs makes sense since they likely don't have the social power or knowledge to make these other suggestions. Also those suggestions can be important in the early stage of a project to set precedence

I disagree with code style as a fixation. It's much better to have a uniform style if it improves the readability of the code.

I think the most important thing is to not make a fixation a 20 hour discussion.

I'm not sure the "Environments" he cites are good examples for most types of software development.

Mathematica, MATLAB, Lisp, Smalltalk, are all development environments where there are a lot of questions around how to best deploy the software after you have written it. Maybe in some cases you have enough control over the customer environment where you can tell them "Just install MATLAB, then run this code we are giving you."

But what if the requirements are to deliver an iOS or Android app? What if you are building a web service? Or an embedded system? Or a game for a specific console?

Continuous integration and deployment are too very important problems that need to be carefully considered when deciding on or creating an Environment.

"What we want is a vehicle for exploring that space -- something like an IDE for your problem domain. It's been joked that any problem in computing can be solved with another level of indirection, but 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."

To this Lisp programmer, this sounds like plain old bottom-up design. I'm making primitives and syntax for The Thing I Want. My IDE essentially is an IDE for my problem domain.

It's a bit harder in other languages, but still more or less feasible. I think many people would be surprised by how much of my software is written in itself.

Most 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.

Software engineering is the blend of software, business and people. When the business is itself purely about software, and the sole team member is yourself, then I agree with the article.

The ultimate currency in software engineering is time. Time spent on ideation, time spent on requirement gathering, time spent on designing, time spent on communicating ideas, time spent on iterating features, time spent on maintaining existing codes.

If going through the hierarchy saves you time, by all means do it.

It's odd that he incidentally refers to "architecture" a couple of times but doesn't include that in the hierarchy. I'd put architecture above models because it defines not just how your models are partitioned and connected but how they communicate. Also, good architecture isn't an answer to here-and-now requirements but anticipates how an entire system might need to adapt to _future_ requirements.

Architecture is a word used by many people in software.

I ask the author of this article: have you looked at the definition of software architecture?

ISO, IEC and IEEE agree on what software architecture means.

Quality, as in code quality, is an architectural concern. Good practices are an architectural concern.

If you downplay the role of good software engineering practices as unimportant bikeshedding you cannot call yourself an architect.

"Requirements" is an often-misleading word. The danger is putting the customers on a pedestal while at the same time not really listening or understanding.

Supposed "requirements" are sometimes merely design preferences. Customers will often trade them for other things they want more (time to delivery, higher priority features, alternative implementations) if given a chance. Unless you have a good relationship with the customer so you can negotiate these tradeoffs, you may build something that meets requirements but isn't what they really want.

Very 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.

Where does "coming up with new manifestos" fit in? Because that's a demonstrably integral part of software engineering, too.

I think it depends on the problem set and where one works, etc. There's a lot of use cases where getting it over the wall is perfectly acceptable and what the business needs. I can cite numerous incidents where a lot of code was design, written, and then out of circulation less than a couple years later. I also know of instances where some crappy code stuck and is in use 14 years later. The hard part is knowing which is what, and some of this can be alleviated by a decent modular design and taking on tech debt to refactoring/swapping out certain implementations for more robust implementations at a future date. It's hard to balance delivery time frames with robust/clean code, especially when so many opinions drive the later. Hopefully you get to work in a place that favors the slower, better planned approach approach.

"don't debate test coverage, code design, etc. and just get the job done because meeting requirements is all that matters"

I would say:

"Don't debate test coverage, code design, etc., unless they are relevant to meeting the customer's requirements."

Now, many times, these things are very relevant to meeting the requirements! Without tests, the odds of your code actually meeting the requirements is very low. Instead of finding and fixing problems with the code before it gets to customers, you get to fix it after you give it to customers and it fails, and you've probably just lost those customers.

To the "code design" point, I think that is covered in the "Models" section. Modeling the problem correctly leads very straightforwardly to getting the right design.

Maybe you didn’t scroll down? That’s only the second item in a hierarchy of 5.

New DSLs/notations aren't conceptually different or more difficult than different libraries with differing APIs. In fact, each time you're coding to an API of a library, you are coding to a DSL - the API is the language. Writing real DSLs via code transformators/generators (e.g. macros in Lisp) just removes the noise caused by the mismatch between the API and the language syntax, making things potentially cleaner once you understand the API.

Documentation is still crucial, whether you're dealing with a library or a DSL.

For the last year or so, I've been fascinated by this concept, and I've been exploring language oriented programming with Racket. There was some discussion on this topic and the Beautiful Racket book here a while back [1]. That book is the best introduction I've found to the idea that you can build your notation to the problem you are solving.

Re: painting yourself into a corner, it is true that you can't retreat to Stack Overflow for help debugging your DSL, but the Racket documentation is some of the best I've seen, and common problems do pop up on SO.

[1] https://news.ycombinator.com/item?id=19232068

You might be interested in our project (https://treenotation.org). Gone are all syntax characters like {}[](), which turn a 1D stream of tokens into an AST. Instead you simply write your source in 2-dimensional notation.

Makes it far easier to build new DSLs. (Evidence: see all the DSLs in GitHub.com/treenotation/jtree/langs)

> In modern times, I can think of two languages that seem to have been built to provide solutions in specific problem domains:

The obvious one to me is `R`!