4 ms·

Unpopular opinion: There is not nearly enough design in most software development these days. Any sort of reasonable planning and writing and spec-ing tends to

Unpopular opinion: There is not nearly enough design in most software development these days. Any sort of reasonable planning and writing and spec-ing tends to be derided as "waterfall"/Big Design Up Front and therefore inherently bad. You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! Then they get frustrated they don't get time to fix their tech debt. How about not going so into debt in the first place? By all means do some prototyping but then throw it away after a week or two. Use it to test hypotheses you've already written down somewhere. You'll have more success if you're asking for two weeks to clean up tech debt instead of two months.

nine_zeros 3y ago
> You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! In whatever BS performance review process in your company, are engineers going to be recognized for writing documents, meetings, talking to future and end users? If yes, engineers will do it. As it stands, in large companies, management just wants engineers to code their life out.
- wldcordeiro 3y ago
  In my experience even when you want to do those things more often than not it's management that sees it as a waste of time and wants you to get to coding. So many times we've had to "pivot" in projects because management couldn't be bothered to let us plan any architecture.
  - ChikkaChiChi 3y ago
    I think this is the failure of the project leaders to incorporate usability into the discussion from the outset. It takes a strong will to sit there and say "We can build you what you want, but without at least one pass on usability and optimization, it's going to be fat, slow, and the end users are going to hate it."
- 8n4vidtmkvmk 3y ago
  Documents yes, meetings no but also secretly yes. Documents are an artifact you can point to, and getting comments and references also looks good. Managers don't care how many hours you sit in meetings, but if you magically show leadership by driving meetings and somehow document that, then it counts. No one talks to end users though not engineers anyway. We just build dumb things the PMs want.
no_wizard 3y ago
Ironically extreme programming (the first real iteration of Agile) was big on getting requirements, creating what some call spikes (POCs of concepts or demos), and talking to stakeholders as one of the key priorities. The chunking of 2 week sprints is a natural result of this, where the idea is you get together alot in the first few days of a sprint, plan some loose but defined stuff, iterate on it, come back for a day or two in the middle, re-iterate, and then show your work and plan the next cycle. Work should be introduced in such a way it can be chunked in small pieces like this. This is why TDD became highly coupled to Aigle/XP by the original practitioners around Agile development. Tests are your first validation of an idea, a way to write code-as-documentation and feature validation, before you actually implemented the thing in the product line. (side note: TDD has bee distorted too, by both "zealots" and the opposition, largely lost its original intent and execution) The real problem, as I have observed, is that everyone is still waterfall or some version of "waterfall lite" and doesn't actually observe the intentions behind Agile. Its been completely devoid of the meaning behind the original manifesto. Hardly any place follows it in its true form, I feel.
feoren 3y ago
Completely agree, but you're implicitly assuming that developers have a lot of leeway in doing this design in the first place. Many non-technical managers seem to assume that developers should not have any say in the design and functionality of the product. I think this is a huge mistake -- I think software engineers are the best people to ultimately make decisions about how the product should work (with heavy input from stakeholders and users, of course) -- but the reality is that managers often don't trust them to do this and don't cede this power to them.
UK-AL 3y ago
It's useful, but i find most design doesn't tend to be driven by the engineers themselves. So you end up design focus on things that don't matter, and things that do get skipped over.
8n4vidtmkvmk 3y ago
The problem with meetings and design docs is that not many people will take the time to really grasp the problem. The comments are usually only superficially about the stuff you did write and rarely point out anything you missed entirely. Everyone has their own stuff going on so unless your work overlaps with theirs, no one is interested.
paulryanrogers 3y ago
Considering all the design churn I see in products large and small, I'd say the pendulum often swings in the other direction. Vanity changes appear with little or no thought to accessibility, often regressing for all except the slice of rich, young, clear-sighted, able-bodied people with fast internet and a recent Mac model.

nine_zeros 3y ago

> You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! In whatever BS performance review process in your company, are engineers going to be recognized for writing documents, meetings, talking to future and end users? If yes, engineers will do it. As it stands, in large companies, management just wants engineers to code their life out.

wldcordeiro 3y ago
In my experience even when you want to do those things more often than not it's management that sees it as a waste of time and wants you to get to coding. So many times we've had to "pivot" in projects because management couldn't be bothered to let us plan any architecture.
- ChikkaChiChi 3y ago
  I think this is the failure of the project leaders to incorporate usability into the discussion from the outset. It takes a strong will to sit there and say "We can build you what you want, but without at least one pass on usability and optimization, it's going to be fat, slow, and the end users are going to hate it."
8n4vidtmkvmk 3y ago
Documents yes, meetings no but also secretly yes. Documents are an artifact you can point to, and getting comments and references also looks good. Managers don't care how many hours you sit in meetings, but if you magically show leadership by driving meetings and somehow document that, then it counts. No one talks to end users though not engineers anyway. We just build dumb things the PMs want.

no_wizard 3y ago

Ironically extreme programming (the first real iteration of Agile) was big on getting requirements, creating what some call spikes (POCs of concepts or demos), and talking to stakeholders as one of the key priorities. The chunking of 2 week sprints is a natural result of this, where the idea is you get together alot in the first few days of a sprint, plan some loose but defined stuff, iterate on it, come back for a day or two in the middle, re-iterate, and then show your work and plan the next cycle. Work should be introduced in such a way it can be chunked in small pieces like this. This is why TDD became highly coupled to Aigle/XP by the original practitioners around Agile development. Tests are your first validation of an idea, a way to write code-as-documentation and feature validation, before you actually implemented the thing in the product line. (side note: TDD has bee distorted too, by both "zealots" and the opposition, largely lost its original intent and execution) The real problem, as I have observed, is that everyone is still waterfall or some version of "waterfall lite" and doesn't actually observe the intentions behind Agile. Its been completely devoid of the meaning behind the original manifesto. Hardly any place follows it in its true form, I feel.

feoren 3y ago

Completely agree, but you're implicitly assuming that developers have a lot of leeway in doing this design in the first place. Many non-technical managers seem to assume that developers should not have any say in the design and functionality of the product. I think this is a huge mistake -- I think software engineers are the best people to ultimately make decisions about how the product should work (with heavy input from stakeholders and users, of course) -- but the reality is that managers often don't trust them to do this and don't cede this power to them.

UK-AL 3y ago

It's useful, but i find most design doesn't tend to be driven by the engineers themselves. So you end up design focus on things that don't matter, and things that do get skipped over.

8n4vidtmkvmk 3y ago

The problem with meetings and design docs is that not many people will take the time to really grasp the problem. The comments are usually only superficially about the stuff you did write and rarely point out anything you missed entirely. Everyone has their own stuff going on so unless your work overlaps with theirs, no one is interested.

paulryanrogers 3y ago

Considering all the design churn I see in products large and small, I'd say the pendulum often swings in the other direction. Vanity changes appear with little or no thought to accessibility, often regressing for all except the slice of rich, young, clear-sighted, able-bodied people with fast internet and a recent Mac model.