8 ms·

So we have come full circle. That's the way we have been building software when I was starting with professional software development (this was around 2005). Bu

So we have come full circle. That's the way we have been building software when I was starting with professional software development (this was around 2005). But the idea of doing a thorough analysis (business, technical) is a little bit older. The only people to whom this might come as a surprise are the ones who've drank too much of the "agile Kool-aid". I'm not here to bash agile and start this flame war all over again (agile has it's merits ...), but somehow thinking before doing got a bad rap recently (for reasons beyond me). It's like software development got trapped inside of King Julian's (from Madagascar movies/series) brain with his modus operandi: "let's start doing this before we figure out it does not make any sense".

shreyshnaccount 4y ago
Because thinking clearly is the hard part. I use Github copilot every day for work (and it generates decent code completion for me) and the only thing I've realised is that the major work in programming is to think clearly, and converting thoughts to syntax is not really that hard. Copilot takes off that easier cognitive workload and helps me focus and clear my thoughts. Also, does anyone know how to think clearly or does that just come with practice and experience?
- brzezmac 4y ago
  Thinking, especially abstract thinking, is crucial to software development, as often (not always) creating software is abstracting real life into algorithms and data structures. Writing text in a word procesor, notepad, etc. is in my opinion first step to validation of the idea, to having at least faint idea about the complexity of the solution we would like to build. On the question of "how to think clearly" - I'd say it's pretty individual - some people start "from the bottom", some "from the top" and others "in the middle". Experience is to know which is which and which approach suits you best.
  - shreyshnaccount 4y ago
    Wise words. That's prolly why you need to be good at math to be good at tech, abstract thinking all the way
pydry 4y ago
>somehow thinking before doing got a bad rap recently (for reasons beyond me). I've seen plenty of software devs engage in detailed forward planning for a future that would be utterly different from what they expected. Best case this rendered all that forward planning moot and a waste of time. Medium case is they did a lot of pointless work. Worst case they technologically straitjacketed themselves and dug multiple holes they couldnt extricate themselves from easily. Then they'd pick themselves up and do it all over again thinking that if they (or more usually somebody else) just managed to predict the future better then this kind of shit wouldnt happen. E.g. those idiot PMs just need to provide better requirements. It's a hard rut to get out of because in so many other spheres of life forward upfront planning is critical and the future IS predictable. Software intuitively feels like it should be too. But it's the exact fucking opposite of that. This is, at least, why certain kinds of thinking before doing got a bad rap with me.
- Dudeman112 4y ago
  Sounds like a problem with the execution instead of the technique. The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be. We basically developed whole-ass treatises (and some unhealthy cargo cults) around people saying that the observe -> think -> do -> restart loop should be small and leave space for adjustments between each step.
  - AnimalMuppet 4y ago
    > The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be. When I was a kid, we topped over this hill on the interstate, and way down in the distance there was an overpass across the road, with straight road from here to there. And I wondered how my dad could aim the car so well that it would go under that overpass way off in the distance. Of course, now I know that he didn't do that. He didn't even try to do that. Instead, he steered the car. The alternative to thinking before doing is not wandering aimlessly. It's steering. It's knowing where you're trying to go, even if you don't exactly know how to get there, and having an initial idea of how to get there, and then starting to go there, and adjusting as you find obstacles that you didn't know existed, and as you find that your aim was off.
usrbinbash 4y ago
Agile and Documentation-Driven-Development can not only easily go hand in hand, I think agile is perfectly suited to work like this. We figure out what the software is supposed to do -> We write documentation describing that -> We build the implementation -> New Requirements -> Figure out how to incorporate them into the plan -> Update the documentation -> Build the changes. It's an iterative process, perfectly suited to agile development.
- euroderf 4y ago
  I would assume that an agile process will rely on Markdown, but then it some point does it get (irreversibly) committed to a more conventional document format.
  - usrbinbash 4y ago
    If assume (please correct me if I'm wrong) by "conventional document format" you mean ones that do not play well with version control software like git (eg. because they may be/contain huge binary blobs), yes? If so, at least in the projects I am involved in, all documentation that is checked into the repos remains in markdown (asciidoc is also used alot), and is only converted to non-plaintext formats for the purposes of release. This is similar to how we build executables from our source code, but don't check in the resulting binary files into the repo.
    - euroderf 4y ago
      Yes, by "conventional document format" I meant something in the Microsoft crapiverse. Keeping it in markdown/asciidoc sounds great if you can make it work. Is your work in technical environments ? Where people have no expectation of using MS Word ? And those users that need fancy features like footnotes can learn how to use them and then retain that knowledge and use the features without inadvertantly document damage ? I ask because I worked TC in a software firm targeting Microsoft platforms, so they relied on Word (and Sharepoint), and were resistant to ideas of XML and structured documentation, and Markdown never even raised its head.
rkangel 4y ago
The phrase I hang on to is something thrown out by someone I used to work with - "Agile isn't an excuse not to do things". Too many organisation use "we're doing Agile" as an excuse not to do any design thinking and instead "just code". What Agile actually is (in the most general terms) is a different order of doing things that increases the amount of knowledge you have when you do it, and reduces the chances of wasting your work. In my example, you still do the design work, but rather than doing it for the whole system at once you do it for the piece you're about to do, and then implement that piece[1]. But yes, it's nice that the internet has discovered Waterfall! [1] Although many systems, even in an agile world, do require a degree of up front "whole system" architecture and/or design thinking.
indymike 4y ago
I think you can sum it up this way: be planning heavy where it makes sense, and agile where it makes sense. There is not true one way. I'd not want to use agile to develop the formula language in a spreadsheet, and I'd not want to waterfall a marketing website for a product that is speculative. Common sense applies.

shreyshnaccount 4y ago

Because thinking clearly is the hard part. I use Github copilot every day for work (and it generates decent code completion for me) and the only thing I've realised is that the major work in programming is to think clearly, and converting thoughts to syntax is not really that hard. Copilot takes off that easier cognitive workload and helps me focus and clear my thoughts. Also, does anyone know how to think clearly or does that just come with practice and experience?

brzezmac 4y ago
Thinking, especially abstract thinking, is crucial to software development, as often (not always) creating software is abstracting real life into algorithms and data structures. Writing text in a word procesor, notepad, etc. is in my opinion first step to validation of the idea, to having at least faint idea about the complexity of the solution we would like to build. On the question of "how to think clearly" - I'd say it's pretty individual - some people start "from the bottom", some "from the top" and others "in the middle". Experience is to know which is which and which approach suits you best.
- shreyshnaccount 4y ago
  Wise words. That's prolly why you need to be good at math to be good at tech, abstract thinking all the way

pydry 4y ago

>somehow thinking before doing got a bad rap recently (for reasons beyond me). I've seen plenty of software devs engage in detailed forward planning for a future that would be utterly different from what they expected. Best case this rendered all that forward planning moot and a waste of time. Medium case is they did a lot of pointless work. Worst case they technologically straitjacketed themselves and dug multiple holes they couldnt extricate themselves from easily. Then they'd pick themselves up and do it all over again thinking that if they (or more usually somebody else) just managed to predict the future better then this kind of shit wouldnt happen. E.g. those idiot PMs just need to provide better requirements. It's a hard rut to get out of because in so many other spheres of life forward upfront planning is critical and the future IS predictable. Software intuitively feels like it should be too. But it's the exact fucking opposite of that. This is, at least, why certain kinds of thinking before doing got a bad rap with me.

Dudeman112 4y ago
Sounds like a problem with the execution instead of the technique. The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be. We basically developed whole-ass treatises (and some unhealthy cargo cults) around people saying that the observe -> think -> do -> restart loop should be small and leave space for adjustments between each step.
- AnimalMuppet 4y ago
  > The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be. When I was a kid, we topped over this hill on the interstate, and way down in the distance there was an overpass across the road, with straight road from here to there. And I wondered how my dad could aim the car so well that it would go under that overpass way off in the distance. Of course, now I know that he didn't do that. He didn't even try to do that. Instead, he steered the car. The alternative to thinking before doing is not wandering aimlessly. It's steering. It's knowing where you're trying to go, even if you don't exactly know how to get there, and having an initial idea of how to get there, and then starting to go there, and adjusting as you find obstacles that you didn't know existed, and as you find that your aim was off.

usrbinbash 4y ago

Agile and Documentation-Driven-Development can not only easily go hand in hand, I think agile is perfectly suited to work like this. We figure out what the software is supposed to do -> We write documentation describing that -> We build the implementation -> New Requirements -> Figure out how to incorporate them into the plan -> Update the documentation -> Build the changes. It's an iterative process, perfectly suited to agile development.

euroderf 4y ago
I would assume that an agile process will rely on Markdown, but then it some point does it get (irreversibly) committed to a more conventional document format.
- usrbinbash 4y ago
  If assume (please correct me if I'm wrong) by "conventional document format" you mean ones that do not play well with version control software like git (eg. because they may be/contain huge binary blobs), yes? If so, at least in the projects I am involved in, all documentation that is checked into the repos remains in markdown (asciidoc is also used alot), and is only converted to non-plaintext formats for the purposes of release. This is similar to how we build executables from our source code, but don't check in the resulting binary files into the repo.
  - euroderf 4y ago
    Yes, by "conventional document format" I meant something in the Microsoft crapiverse. Keeping it in markdown/asciidoc sounds great if you can make it work. Is your work in technical environments ? Where people have no expectation of using MS Word ? And those users that need fancy features like footnotes can learn how to use them and then retain that knowledge and use the features without inadvertantly document damage ? I ask because I worked TC in a software firm targeting Microsoft platforms, so they relied on Word (and Sharepoint), and were resistant to ideas of XML and structured documentation, and Markdown never even raised its head.

rkangel 4y ago

The phrase I hang on to is something thrown out by someone I used to work with - "Agile isn't an excuse not to do things". Too many organisation use "we're doing Agile" as an excuse not to do any design thinking and instead "just code". What Agile actually is (in the most general terms) is a different order of doing things that increases the amount of knowledge you have when you do it, and reduces the chances of wasting your work. In my example, you still do the design work, but rather than doing it for the whole system at once you do it for the piece you're about to do, and then implement that piece[1]. But yes, it's nice that the internet has discovered Waterfall! [1] Although many systems, even in an agile world, do require a degree of up front "whole system" architecture and/or design thinking.

indymike 4y ago

I think you can sum it up this way: be planning heavy where it makes sense, and agile where it makes sense. There is not true one way. I'd not want to use agile to develop the formula language in a spreadsheet, and I'd not want to waterfall a marketing website for a product that is speculative. Common sense applies.