6 ms·

Too many software charlatans with too big responsibilities (architecture/strategy), with too many books read that were written by evangelists and way too little

Too many software charlatans with too big responsibilities (architecture/strategy), with too many books read that were written by evangelists and way too little experience in whole software development lifecycle. Write software, 1.5 year later update CV with fancy buzzwords you used, change job for better comp and repeat. Who cares how did the design mature? They always have some method/approach which is unparallelled in every metric, except it being reflected in reality. Years of brainwash caused new developers to make strange looks if you use "if" statement or write comments in your code. Also acting as if design pattern was some holy code instead of just a name for an approach to some problem (just normal code, but with name).

mkl95 3y ago
> Write software, 1.5 year later update CV with fancy buzzwords you used, change job for better comp and repeat. Who cares how did the design mature? That's on their employer for offering subpar comp. They could have offered that employee a raise instead, and asked him to rewrite his bad code.
- greenyoda 3y ago
  > They could have offered that employee a raise instead, and asked him to rewrite his bad code. Why would an employee deserve a raise if they write bad code that has to be rewritten?
  - mkl95 3y ago
    Usually you don't get a raise because you deserve it, you get it because the company believes keeping you will result in a more positive financial outcome in the next few quarters than replacing you. Plenty of companies give their engineers a chance to pay their tech debt, whether it is bad code, bad infra decisions, etc. If you don't believe some engineer is capable of paying their tech debt, you may as well let them go. Or not give them a raise and hope they leave, which at most places is much cheaper.
diarrhea 3y ago
The aversion to comments is especially painful. There is no such thing as self-descriptive code. Same with if statements. There is a point to be made about encoding logic in the type system (type-state pattern), which is great. However, encoding it in indirection and abstraction in the name of saving a couple of lines of imperative code is an especially egregious cancer.
- onlypositive 3y ago
  Code tells me what you wanted to achieve. Comments tell me why you needed to. The problem developers have is they assume it's obvious why things are needed. It's usually not obvious 6 months from now, even if you wrote it.
  - pydry 3y ago
    Why from a user level belongs in executable specifications. Why from an implementation level belongs in comments, but that should be fairly rare. Most code shouldn't provoke the question "why on earth did they implement it like this?"
    - onlypositive 3y ago
      Most of my job is figuring out why things were built the way they were. That's the only way I can know if I'm making the right changes without breaking something else in the process. That is to say, sure most code is obvious. I don't work on most code. I work on the parts that need fixing.
  - mumblemumble 3y ago
    No, comments tell me what you wanted to achieve. Code only tells me what you actually achieved. Winston Royce's (fantastic) 1970 paper "Managing the Development of Large Software Systems" accurately anticipated how things would end up working 30+ years later in shops that try to use 'self-documenting' code as a substitute for good documentation. > Without good documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area. > When system improvements are in order, good documentation permits effective redesign, updating, and retrofitting in the field. If documentation does not exist, generally the entire existing framework of operating software must be junked, even for relatively modest changes. Add modern-day turnover rates on technical teams, so that the person who originally wrote the code is unlikely to be around to help with analyzing problems, and you've got an excellent recipe for the current chronic burnout status quo. https://www.praxisframework.org/files/royce1970.pdf https://www.praxisframework.org/files/royce1970.pdf
mcdonje 3y ago
Wait, what's wrong with if-statements? I apparently missed the boat on that one.
- sclarisse 3y ago
  It really depends. Sometimes people try to stuff way too much strategy-picking in if-conditions when they ought to delegate the behavior to some strategy-objects instead, where each code path could be better understood and tested in isolation. (Subclassing can also work here but it’s less flexible.) I also particularly dislike it when you’re trying to support two different formats of payload in the same API, and if() based on presence of the new field. Expedient, I’ll grant, but if not reversed quickly it’s soon absolutely unintelligible. The more-stable systems which have to support clients sending older formats do better by versioning the format, and just having multiple implementations doing whole-payload validation, and delegating to the same underlying task-object (you do have one of those outside the class that’s just about interfacing with HTTP, right? ... okay that’s fine, I understand, but you’re gonna do it now.) On the other hand, sometimes an if-statement is the logic itself. That’s fine.
- mumblemumble 3y ago
  A lot of it's down to a paradigm conflict. In general, if statements are fine. But they're not really considered to be object-oriented. Smalltalk technically doesn't even have an if statement. I will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Subclassing is supposed to be used for a "don't ask, tell" style of programming. A lot of the problems with OOP that people like to complain about aren't really problems with object-oriented programming, per se; they're problems that crop up when object-oriented and procedural programming are mixed in an uncontrolled manner.
  - hardware2win 3y ago
    >will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Suppose you have AST which has Node and its various subclasses like ExpressionNode, which then has e.g ConstantExpressionNoee And so on, many, many other How would you then avoid branching basing on type?
bob1029 3y ago
I've been solving a lot of codebase pattern/anti-pattern nonsense by pushing all of the types, properties and relationships into SQL. It took me about a decade to get to the point where I was done trying to be more clever than 40+ years of computer science aggregated into one magical box. A well-designed schema & clean SQL is an ego killer. It is so goddamned boring. Who would want to work on something that easy? Where did all the code go!? I'd argue database-centric design is the only rational place to start if there is money on the table. Done correctly, this forces you to have deep & meaningful conversations with business stakeholders and customers. It was arguably the only way to build this stuff until the resume stat padders wandered into the job market and started throwing nu-SQL & "patterns" at everything that moved, or otherwise drew everyone's attention away from what is effectively a perfect solution for 99.99% of business needs.
- fellowniusmonk 3y ago
  Completely agree, show me the data and I'll tell you if your solution matches the problem you are trying to solve. So much impedance is unclear thinking and overly complex solutions, it usually combines with inconsistent naming schemes across the stack. It's easier to gatekeep if you're the only who knows a "game" equals a "contestQuest" because you've created some overloaded polymorphic "quest" system in your backend.
Dave3of5 3y ago
I think you are describing a dogmatic approach to development. It's very common and causes problems like are described in the article.
manvillej 3y ago
The best thing I ever did was have a personal project that I've been on for 7 years. It forced me to design in an intuitive, tested, structured way. Because I will come back to an area in a few months and not know what the hell is going on.

mkl95 3y ago

> Write software, 1.5 year later update CV with fancy buzzwords you used, change job for better comp and repeat. Who cares how did the design mature? That's on their employer for offering subpar comp. They could have offered that employee a raise instead, and asked him to rewrite his bad code.

greenyoda 3y ago
> They could have offered that employee a raise instead, and asked him to rewrite his bad code. Why would an employee deserve a raise if they write bad code that has to be rewritten?
- mkl95 3y ago
  Usually you don't get a raise because you deserve it, you get it because the company believes keeping you will result in a more positive financial outcome in the next few quarters than replacing you. Plenty of companies give their engineers a chance to pay their tech debt, whether it is bad code, bad infra decisions, etc. If you don't believe some engineer is capable of paying their tech debt, you may as well let them go. Or not give them a raise and hope they leave, which at most places is much cheaper.

diarrhea 3y ago

The aversion to comments is especially painful. There is no such thing as self-descriptive code. Same with if statements. There is a point to be made about encoding logic in the type system (type-state pattern), which is great. However, encoding it in indirection and abstraction in the name of saving a couple of lines of imperative code is an especially egregious cancer.

onlypositive 3y ago
Code tells me what you wanted to achieve. Comments tell me why you needed to. The problem developers have is they assume it's obvious why things are needed. It's usually not obvious 6 months from now, even if you wrote it.
- pydry 3y ago
  Why from a user level belongs in executable specifications. Why from an implementation level belongs in comments, but that should be fairly rare. Most code shouldn't provoke the question "why on earth did they implement it like this?"
  - onlypositive 3y ago
    Most of my job is figuring out why things were built the way they were. That's the only way I can know if I'm making the right changes without breaking something else in the process. That is to say, sure most code is obvious. I don't work on most code. I work on the parts that need fixing.
- mumblemumble 3y ago
  No, comments tell me what you wanted to achieve. Code only tells me what you actually achieved. Winston Royce's (fantastic) 1970 paper "Managing the Development of Large Software Systems" accurately anticipated how things would end up working 30+ years later in shops that try to use 'self-documenting' code as a substitute for good documentation. > Without good documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area. > When system improvements are in order, good documentation permits effective redesign, updating, and retrofitting in the field. If documentation does not exist, generally the entire existing framework of operating software must be junked, even for relatively modest changes. Add modern-day turnover rates on technical teams, so that the person who originally wrote the code is unlikely to be around to help with analyzing problems, and you've got an excellent recipe for the current chronic burnout status quo. https://www.praxisframework.org/files/royce1970.pdf https://www.praxisframework.org/files/royce1970.pdf

mcdonje 3y ago

Wait, what's wrong with if-statements? I apparently missed the boat on that one.

sclarisse 3y ago
It really depends. Sometimes people try to stuff way too much strategy-picking in if-conditions when they ought to delegate the behavior to some strategy-objects instead, where each code path could be better understood and tested in isolation. (Subclassing can also work here but it’s less flexible.) I also particularly dislike it when you’re trying to support two different formats of payload in the same API, and if() based on presence of the new field. Expedient, I’ll grant, but if not reversed quickly it’s soon absolutely unintelligible. The more-stable systems which have to support clients sending older formats do better by versioning the format, and just having multiple implementations doing whole-payload validation, and delegating to the same underlying task-object (you do have one of those outside the class that’s just about interfacing with HTTP, right? ... okay that’s fine, I understand, but you’re gonna do it now.) On the other hand, sometimes an if-statement is the logic itself. That’s fine.
mumblemumble 3y ago
A lot of it's down to a paradigm conflict. In general, if statements are fine. But they're not really considered to be object-oriented. Smalltalk technically doesn't even have an if statement. I will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Subclassing is supposed to be used for a "don't ask, tell" style of programming. A lot of the problems with OOP that people like to complain about aren't really problems with object-oriented programming, per se; they're problems that crop up when object-oriented and procedural programming are mixed in an uncontrolled manner.
- hardware2win 3y ago
  >will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Suppose you have AST which has Node and its various subclasses like ExpressionNode, which then has e.g ConstantExpressionNoee And so on, many, many other How would you then avoid branching basing on type?

bob1029 3y ago

I've been solving a lot of codebase pattern/anti-pattern nonsense by pushing all of the types, properties and relationships into SQL. It took me about a decade to get to the point where I was done trying to be more clever than 40+ years of computer science aggregated into one magical box. A well-designed schema & clean SQL is an ego killer. It is so goddamned boring. Who would want to work on something that easy? Where did all the code go!? I'd argue database-centric design is the only rational place to start if there is money on the table. Done correctly, this forces you to have deep & meaningful conversations with business stakeholders and customers. It was arguably the only way to build this stuff until the resume stat padders wandered into the job market and started throwing nu-SQL & "patterns" at everything that moved, or otherwise drew everyone's attention away from what is effectively a perfect solution for 99.99% of business needs.

fellowniusmonk 3y ago
Completely agree, show me the data and I'll tell you if your solution matches the problem you are trying to solve. So much impedance is unclear thinking and overly complex solutions, it usually combines with inconsistent naming schemes across the stack. It's easier to gatekeep if you're the only who knows a "game" equals a "contestQuest" because you've created some overloaded polymorphic "quest" system in your backend.

Dave3of5 3y ago

I think you are describing a dogmatic approach to development. It's very common and causes problems like are described in the article.

manvillej 3y ago

The best thing I ever did was have a personal project that I've been on for 7 years. It forced me to design in an intuitive, tested, structured way. Because I will come back to an area in a few months and not know what the hell is going on.