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
A hierarchy of software engineering discourse
31–40 of 54 posts
Re: A hierarchy of software engineering discourse
#32The 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 be…
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.
Re: A hierarchy of software engineering discourse
#33I 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.
Re: A hierarchy of software engineering discourse
#34Seems 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, t…
"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 o…
The problem is the only constant is change. Customer requirements are rarely static. So it's incredibly important to put thought into designing code that's also flexible and maintainable. Because what will happen is customer will inevitably thought of feature X or find bug Y and if they find out it takes a week to fix it, they won't be happy.
But I get what you say about doing those other things to make sure you don't run into the problem of changing requirements.
Part of the problem though is the varied skill level of developers and adequately timing the completion of these tasks. Most companies never budget appropriately for design and just expect banged out code. And there's not enough push back from developers on this, therefore it's become an expectation.
Re: A hierarchy of software engineering discourse
#35I'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 giv…
If you are using Matlab you can embed the runtime and the program in an executable. If you target embedded you generate c-code. Both are $$$ addons and works quite well.
If you really want the customer to run some script "nativly" I would write it for Octave.
Re: A hierarchy of software engineering discourse
#36> 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 thing that makes the thing I want IS the language simply put. More completely it's the environment, architecture, language, requirements, customer, experience and team. I've rarely found a need for a generator that wouldn't be more simply and universally solved via a configuration pattern.
Generating tests from a specification or operations from a schema don't seem to fall into this category.
Re: A hierarchy of software engineering discourse
#37The 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 be…
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)
Re: A hierarchy of software engineering discourse
#38I 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.
Yeah, I think there's a neglect to address that these fixations and best practices are meant to address collaboration and maintenance in a code base. Just cranking out a solution without regard to how others will have to maintain your code does not work so well on a team IMHO.
Re: A hierarchy of software engineering discourse
#39Architecture 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.
Re: A hierarchy of software engineering discourse
#40> 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.
IMO, Calculator Construction Set is a better example (https://www.folklore.org/StoryView.py?story=Calculator_Const...)
Pinball Construction Set (https://en.wikipedia.org/wiki/Pinball_Construction_Set) takes that a step further, not only allowing you to change colors and patterns, but truly allowing you to change the pinball machine.
And of course, there’s tools such as dBase II, Excel, Visual Basic and HyperCard.