3 ms·

Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, proto

Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever. Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things they've not yet thought about.

yamtaddle 4y ago
I'd agree that an awful lot of the problems I run into are dumb trivial shit, once the "real work" starts. This Android component doesn't allow styling without modifying the library object itself, for no good reason aside from whichever intern wrote it was lazy and nobody at Google cares about anything, so it made it through. Ulimit exists, guess I should go fuck myself. AWS says it supports this language for lambdas but it kinda doesn't if you look at the bug tracker for the tools. This fancy new build tool someone else chose breaks this third party package in a way that goes away immediately if I just swap it for the old, uncool build tool. That kind of crap. And it's the worst part of programming. There are also "real" problems, but they're the minority.
torben-friis 4y ago
> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, how to roll it back if you screw up, etc. I find that many people use agile as an excuse to ignore these questions and just pile up fixes on top of prototypes.
- icedchai 4y ago
  Exactly this. Agile is often seen as an excuse to throw out any sort of design. You wind up with fixing the mess made last sprint in the next. But, good news, there are Jira tickets with points assigned for the half-baked fixes!
- randomdata 4y ago
  > Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done. Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
  - torben-friis 4y ago
    > Read the Manifesto again. I did, and here's the direct quotes: > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. As I said, the cycle length is shortened, yet... > Continuous attention to technical excellence and good design enhances agility. ...design is not removed from the process, but kept as a cornerstone. > Simplicity--the art of maximizing the amount of work not done--is essential. This one might be a bit more of a stretch, but I see here the benefit of designing a simple, elegant solution rather than doing work straight ahead. In any case, I don't fully agree with the agile manifesto, even when correctly implemented. Particularly this quote is the bane of my existence: > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Which you can identify as the very opposite of the ever popular 'this meeting could have been an email'.
    - randomdata 4y ago
      Now read it again as the entire document that it is. While I can see where you are coming from, your theme doesn't carry into the points you conveniently left out. Once you put it together, you'll realize that the message is: 1. Deliver software. You won't have a manager hounding you to do so. 2. Do good work. You won't have a manager questioning what you've done. 3. Don't spend more time programming than you need to. You need time for managerial tasks. 4. Meet with your teammates. You won't have a manager to act as the go-between.
      - 4y ago
- Falkon1313 4y ago
  Despite having somehow done this successfully for many years, I still find 2 weeks total for the entirety of requirements gathering, planning, designing, developing, reviewing, and testing (plus all the meetings and documentation and jira cards etc.) is kind of an incomprehensible timeline for anything but the most trivial fix. We're building entire skyscrapers and cathedrals by gluing a few toothpicks together at a time. Because that's all there's time for in a sprint. It shows in the quality of modern software, and the never-ending updates necessary to keep them from collapsing. Of course planning it all out years in advance and then executing blindly on those plans without ever correcting course wouldn't make sense either. But maybe a middle ground could be better than either extreme.
lvmz 4y ago
Problems are often "sticky" (A term I've read referencing this exact thing, a problem where you need to begin implementing before you understand it fully, but I don't think it's a widely used term) but I think the implementation step is a different matter than architecture stuff regardless. It's not that there aren't important things to work out, but for me I broadly consider that to be part of the implementation. I get what you're saying though, I definitely don't think I'm solving all my problems before ever starting the code, but I definitely always finish solving the problem before I finish the code, and usually early enough that the rest of implementation drags even if there are quirks and edge cases to work out.
guywhocodes 4y ago
Yeah this is quite common, somehow I sympathize with both gp and submitter here, the last year I have tried suffered under a group of architects that have greenlit a project where we have now wasted about a man century. All because we ramped up fast into a "fully sovled problem" with new "well understood architectural patterns and design philosophy". And these are not "23 year old CTO" type people, it's people with 25+ years as "enterprise architect" in FAANG type companies. The main lesson I've drawn is that never propose a technical solution that you didn't PoC and that you only have validated the parts of the system you implemented. Deletion is often harder than creation.
birdyrooster 4y ago
I dont know about you but virtually every team still uses waterfall at some scale
escapedmoose 4y ago
True, so if you’re a planning type of person, you need to have realistic expectations about your unknown unknowns. Humility helps. But the people who go straight to the keyboard to figure it out as they go can spin their wheels just as bad.

yamtaddle 4y ago

I'd agree that an awful lot of the problems I run into are dumb trivial shit, once the "real work" starts. This Android component doesn't allow styling without modifying the library object itself, for no good reason aside from whichever intern wrote it was lazy and nobody at Google cares about anything, so it made it through. Ulimit exists, guess I should go fuck myself. AWS says it supports this language for lambdas but it kinda doesn't if you look at the bug tracker for the tools. This fancy new build tool someone else chose breaks this third party package in a way that goes away immediately if I just swap it for the old, uncool build tool. That kind of crap. And it's the worst part of programming. There are also "real" problems, but they're the minority.

torben-friis 4y ago

> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, how to roll it back if you screw up, etc. I find that many people use agile as an excuse to ignore these questions and just pile up fixes on top of prototypes.

icedchai 4y ago
Exactly this. Agile is often seen as an excuse to throw out any sort of design. You wind up with fixing the mess made last sprint in the next. But, good news, there are Jira tickets with points assigned for the half-baked fixes!
randomdata 4y ago
> Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done. Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
- torben-friis 4y ago
  > Read the Manifesto again. I did, and here's the direct quotes: > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. As I said, the cycle length is shortened, yet... > Continuous attention to technical excellence and good design enhances agility. ...design is not removed from the process, but kept as a cornerstone. > Simplicity--the art of maximizing the amount of work not done--is essential. This one might be a bit more of a stretch, but I see here the benefit of designing a simple, elegant solution rather than doing work straight ahead. In any case, I don't fully agree with the agile manifesto, even when correctly implemented. Particularly this quote is the bane of my existence: > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Which you can identify as the very opposite of the ever popular 'this meeting could have been an email'.
  - randomdata 4y ago
    Now read it again as the entire document that it is. While I can see where you are coming from, your theme doesn't carry into the points you conveniently left out. Once you put it together, you'll realize that the message is: 1. Deliver software. You won't have a manager hounding you to do so. 2. Do good work. You won't have a manager questioning what you've done. 3. Don't spend more time programming than you need to. You need time for managerial tasks. 4. Meet with your teammates. You won't have a manager to act as the go-between.
    - 4y ago
Falkon1313 4y ago
Despite having somehow done this successfully for many years, I still find 2 weeks total for the entirety of requirements gathering, planning, designing, developing, reviewing, and testing (plus all the meetings and documentation and jira cards etc.) is kind of an incomprehensible timeline for anything but the most trivial fix. We're building entire skyscrapers and cathedrals by gluing a few toothpicks together at a time. Because that's all there's time for in a sprint. It shows in the quality of modern software, and the never-ending updates necessary to keep them from collapsing. Of course planning it all out years in advance and then executing blindly on those plans without ever correcting course wouldn't make sense either. But maybe a middle ground could be better than either extreme.

lvmz 4y ago

Problems are often "sticky" (A term I've read referencing this exact thing, a problem where you need to begin implementing before you understand it fully, but I don't think it's a widely used term) but I think the implementation step is a different matter than architecture stuff regardless. It's not that there aren't important things to work out, but for me I broadly consider that to be part of the implementation. I get what you're saying though, I definitely don't think I'm solving all my problems before ever starting the code, but I definitely always finish solving the problem before I finish the code, and usually early enough that the rest of implementation drags even if there are quirks and edge cases to work out.

guywhocodes 4y ago

Yeah this is quite common, somehow I sympathize with both gp and submitter here, the last year I have tried suffered under a group of architects that have greenlit a project where we have now wasted about a man century. All because we ramped up fast into a "fully sovled problem" with new "well understood architectural patterns and design philosophy". And these are not "23 year old CTO" type people, it's people with 25+ years as "enterprise architect" in FAANG type companies. The main lesson I've drawn is that never propose a technical solution that you didn't PoC and that you only have validated the parts of the system you implemented. Deletion is often harder than creation.

birdyrooster 4y ago

I dont know about you but virtually every team still uses waterfall at some scale

escapedmoose 4y ago

True, so if you’re a planning type of person, you need to have realistic expectations about your unknown unknowns. Humility helps. But the people who go straight to the keyboard to figure it out as they go can spin their wheels just as bad.