6 ms·

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the diff

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation. Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

AIorNot 7mo ago
“Everyone has a plan until they get punched in the mouth" - Mike Tyson
2OEH8eoCRo0 7mo ago
I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. > Most of what's planned falls down within the first few hours of implementation. Not my experience at all. We know what computers are capable of.
- steveBK123 7mo ago
  > I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool. The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.
  - zingar 7mo ago
    It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect that one line to take 5 minutes, after which you should write lots more code that adds no value. Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.
    - steveBK123 7mo ago
      My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead. To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report. Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API. It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.
      - pixl97 7mo ago
        Heh, sounds like Goodhart's law gone wild at that place.
        steveBK123 7mo ago
        Yes - how to complete story points without actually solving any problems
- zingar 7mo ago
  Comparing the same work done between agile and waterfall I can accept your experience of what sounds like an org with unusually effective long term planning. However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect). Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.
- orthoxerox 7mo ago
  > Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.
  - budman1 7mo ago
    there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate. agile approaches are based on the quick implementations, redone as needed. my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as needed. 4> go to 2 The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)
    - sbarre 7mo ago
      This approach also accounts for the truism that "the customer doesn't know what they want until they don't see it in the final product".
- datsci_est_2015 7mo ago
  > > Most of what's planned falls down within the first few hours of implementation. > Not my experience at all. We know what computers are capable of. You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)
  - sbarre 7mo ago
    Wait, are you perhaps saying that... "it depends"? ;-) Every single reply in this thread is someone sharing their subjective anecdotal experience.. There are so many factors involved in how work pans out beyond planning. Even a single one of us could probably tell 10 different stories about 10 different projects that all went differently.
    - datsci_est_2015 7mo ago
      Yeah, which is also why I tried not to* speak prescriptively, unlike some other comments in this thread…
- goalieca 7mo ago
  Agile is for when you don't know what you're making and you're basically improvising. People forget that.
  - steveBK123 7mo ago
    Correct, and it was applied top-down to teams that do larger infrastructure / implementations in known areas / etc. There are costs to pouring out a cement foundation without thinking through how many floors your building is going to be in advance.
  - budman1 7mo ago
    But if you don't know what you are making, it is the only option!
- alkonaut 7mo ago
  I think it also depends on how people think. I might be able to sit can't sit in a meeting room/white board/documentation editor and come up with what the big problems is (where pain points in implementation will occur, where a sudden quadratic algorithm pops up, where a cache invalidation becomes impossible, ...) even if I stare at this white board or discuss with my peers for days. But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened. They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".
- Hendrikto 7mo ago
  > I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.
  - christophilus 7mo ago
    > If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.
    - Hendrikto 7mo ago
      You summarized agile. That is the whole point: short feedback cycles. You can view it as a series of short, self-regressive waterfalls.
sodapopcan 7mo ago
Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.
- jakevoytko 7mo ago
  I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.
  - yonaguska 7mo ago
    For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.
  - player1234 7mo ago
    [dead]
- hallway_monitor 7mo ago
  You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.
  - palmotea 7mo ago
    > You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion. I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress). Basically, it sounds like turning programming into an all-day meeting. So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.
apexalpha 7mo ago
This might be true for tech companies, but the tech department I am in at a large government could absolutely architecture away >95% of 'problems' we are fixing at the end of the SDLC.
eyelidlessness 7mo ago
It’s a muscle you can exercise, and doing so helps you learn what to focus on so it’ll be successful. IME a very successful approach is to focus on interfaces, especially at critical boundaries (critical for your use case first, then critical for your existing design/architecture). Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations. Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.
ventana 7mo ago
That's actually one thing that always prevented me from following the standard pathway of "write a design document first, get it approved, then execute" during my years in Google. I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to write an actual code, and then you pretty much have code ready, so why bother writing a design doc. Some of my best (in terms of perf consequences) design documents were either completely trivial from the code complexity point of view, so that I did not actually need to write the code to see the system working, or were written after I already had a quick and dirty implementation working.
- nyrikki 7mo ago
  That’s why I either started with the ports and adapters pattern or quickly refactored into it on spikes. You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation. Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better. I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules. Keeping the core domain as a fixed point does that for me.
- RobRivera 7mo ago
  I am very similar in this respect, however once I get to a place where I am implementing something very similar to something in my past, it becomes easier to draft a doc first because I have been down that path before
dotancohen 7mo ago
> Most of what's planned falls down within the first few hours of implementation. Planning is priceless. But plans are worthless.
- kaffekaka 7mo ago
  I am stealing that quote.
  - dotancohen 7mo ago
    I can not claim it )) I think that Eisenhower said it first.
gunsle 7mo ago
Agreed completely. I’ve worked at a couple places that want to design session everything to death and then meticulously convert that design by committee into story requirements to the point that no actual engineering is even needed from the engineer. On top of that, the usual problem occurs - turns out there actually was a lot of unknowns, and now that 2-4 hours you spent with 5-10 other people meticulously crafting the story and execution plan has been completely wasted as the requirements and design shift by extension. It infuriates me to no end that others within the org don’t see how frequently we do redo these meticulously written stories and what a waste of time that is.

AIorNot 7mo ago

“Everyone has a plan until they get punched in the mouth" - Mike Tyson

2OEH8eoCRo0 7mo ago

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. > Most of what's planned falls down within the first few hours of implementation. Not my experience at all. We know what computers are capable of.

steveBK123 7mo ago
> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool. The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.
- zingar 7mo ago
  It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect that one line to take 5 minutes, after which you should write lots more code that adds no value. Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.
  - steveBK123 7mo ago
    My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead. To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report. Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API. It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.
    - pixl97 7mo ago
      Heh, sounds like Goodhart's law gone wild at that place.
      - steveBK123 7mo ago
        Yes - how to complete story points without actually solving any problems
zingar 7mo ago
Comparing the same work done between agile and waterfall I can accept your experience of what sounds like an org with unusually effective long term planning. However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect). Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.
orthoxerox 7mo ago
> Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.
- budman1 7mo ago
  there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate. agile approaches are based on the quick implementations, redone as needed. my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as needed. 4> go to 2 The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)
  - sbarre 7mo ago
    This approach also accounts for the truism that "the customer doesn't know what they want until they don't see it in the final product".
datsci_est_2015 7mo ago
> > Most of what's planned falls down within the first few hours of implementation. > Not my experience at all. We know what computers are capable of. You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)
- sbarre 7mo ago
  Wait, are you perhaps saying that... "it depends"? ;-) Every single reply in this thread is someone sharing their subjective anecdotal experience.. There are so many factors involved in how work pans out beyond planning. Even a single one of us could probably tell 10 different stories about 10 different projects that all went differently.
  - datsci_est_2015 7mo ago
    Yeah, which is also why I tried not to* speak prescriptively, unlike some other comments in this thread…
goalieca 7mo ago
Agile is for when you don't know what you're making and you're basically improvising. People forget that.
- steveBK123 7mo ago
  Correct, and it was applied top-down to teams that do larger infrastructure / implementations in known areas / etc. There are costs to pouring out a cement foundation without thinking through how many floors your building is going to be in advance.
- budman1 7mo ago
  But if you don't know what you are making, it is the only option!
alkonaut 7mo ago
I think it also depends on how people think. I might be able to sit can't sit in a meeting room/white board/documentation editor and come up with what the big problems is (where pain points in implementation will occur, where a sudden quadratic algorithm pops up, where a cache invalidation becomes impossible, ...) even if I stare at this white board or discuss with my peers for days. But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened. They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".
Hendrikto 7mo ago
> I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.
- christophilus 7mo ago
  > If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.
  - Hendrikto 7mo ago
    You summarized agile. That is the whole point: short feedback cycles. You can view it as a series of short, self-regressive waterfalls.

sodapopcan 7mo ago

Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.

jakevoytko 7mo ago
I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.
- yonaguska 7mo ago
  For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.
- player1234 7mo ago
  [dead]
hallway_monitor 7mo ago
You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.
- palmotea 7mo ago
  > You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion. I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress). Basically, it sounds like turning programming into an all-day meeting. So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.

apexalpha 7mo ago

This might be true for tech companies, but the tech department I am in at a large government could absolutely architecture away >95% of 'problems' we are fixing at the end of the SDLC.

eyelidlessness 7mo ago

It’s a muscle you can exercise, and doing so helps you learn what to focus on so it’ll be successful. IME a very successful approach is to focus on interfaces, especially at critical boundaries (critical for your use case first, then critical for your existing design/architecture). Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations. Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.

ventana 7mo ago

That's actually one thing that always prevented me from following the standard pathway of "write a design document first, get it approved, then execute" during my years in Google. I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to write an actual code, and then you pretty much have code ready, so why bother writing a design doc. Some of my best (in terms of perf consequences) design documents were either completely trivial from the code complexity point of view, so that I did not actually need to write the code to see the system working, or were written after I already had a quick and dirty implementation working.

nyrikki 7mo ago
That’s why I either started with the ports and adapters pattern or quickly refactored into it on spikes. You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation. Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better. I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules. Keeping the core domain as a fixed point does that for me.
RobRivera 7mo ago
I am very similar in this respect, however once I get to a place where I am implementing something very similar to something in my past, it becomes easier to draft a doc first because I have been down that path before

dotancohen 7mo ago

> Most of what's planned falls down within the first few hours of implementation. Planning is priceless. But plans are worthless.

kaffekaka 7mo ago
I am stealing that quote.
- dotancohen 7mo ago
  I can not claim it )) I think that Eisenhower said it first.

gunsle 7mo ago

Agreed completely. I’ve worked at a couple places that want to design session everything to death and then meticulously convert that design by committee into story requirements to the point that no actual engineering is even needed from the engineer. On top of that, the usual problem occurs - turns out there actually was a lot of unknowns, and now that 2-4 hours you spent with 5-10 other people meticulously crafting the story and execution plan has been completely wasted as the requirements and design shift by extension. It infuriates me to no end that others within the org don’t see how frequently we do redo these meticulously written stories and what a waste of time that is.