3 ms·

It is useful and efficient to defer making decisions until you have to. But it's critical to avoid waiting too long to make decisions. Because that means the d

by jmull 6y ago

It is useful and efficient to defer making decisions until you have to. But it's critical to avoid waiting too long to make decisions. Because that means the decision was to make no decision, and that has only a random chance to be the right one for you. Planning is a big part of how you have the information you need to know when to make a decision and when to defer it. Plenty of work be organized to fit into ~two-week, focused sprints, and can be done efficiently that way. Use your planning to figure out what should and should not be tackled that way. There's also work where it makes no sense at all to do while looking ahead at most only two weeks. For instance, if you have a good experienced architect, a small amount of time spent on a high-level arcitecture will pay you back on even a slightly successful project. Not to mention it will increase your agility. E.g., don't design a sophisticated privilege mechanism until you know you need it. But if there's a reasonable chance a privilege mechanism will be important in the future, know where one would fit in in a way that wouldn't require a substantial rewrite. Now you'll be able to slot in a simple privilege mechanism, if/when you need one, and later replace/evolve that with a sophisticated one, if needed, all quickly and without substantial rewrites.

dijit 6y ago
I worked on two very large software projects (AAA games count, right?) and failure to make decisions in a timely manner was one of the largest factors in how much the project suffered, both staff and the product. What I mean by that is, the project which did not decide things on time and tried to save the decision until they knew everything suffered much more than the project which decided in a timely manner and re-evaluated the decision in the rare instance that they were wrong. It was greatly inefficient to have people sitting around not knowing if what they’re working on will even be used because they’re touching something that hadn’t been fully decided on yet, but was required for them to deliver on something else which _had_ been decided. It is sometimes better to decide, iterate and reevaluate. Instead of attempting to defer a decision.
- maerF0x0 6y ago
  Analysis paralysis (refusing to make a decision until more research is done, to the detriment of a project) is a different error than delaying a decision until beyond the last viable moment.
lmm 6y ago
> There's also work where it makes no sense at all to do while looking ahead at most only two weeks. > For instance, if you have a good experienced architect, a small amount of time spent on a high-level arcitecture will pay you back on even a slightly successful project. Not to mention it will increase your agility. E.g., don't design a sophisticated privilege mechanism until you know you need it. But if there's a reasonable chance a privilege mechanism will be important in the future, know where one would fit in in a way that wouldn't require a substantial rewrite. Now you'll be able to slot in a simple privilege mechanism, if/when you need one, and later replace/evolve that with a sophisticated one, if needed, all quickly and without substantial rewrites. No. This is the most seductive myth in software development, and it's exactly what Agile exists to avoid. I've worked with experienced architects. I've worked with very intelligent architects. I've worked with extremely highly paid architects. None of them ever managed to add value to the project rather than subtracting it. Write the simplest thing that might possibly work. Write plain code that's easy to refactor. Ensure that your test cases (or better still your type system) capture your business requirements so that you can refactor fearlessly and mercilessly. And as if by magic, retrofitting that sophisticated privilege mechanism will turn out to be easy, because you don't have a bunch of architecture getting in your way.
- aksjfnkajsnd 6y ago
  > (or better still your type system) capture your business requirements How do you mean?
  - lmm 6y ago
    Create types that express the requirements that you have, and use them to ensure that requirements are always met. For example, if some fields should only be accessed by administrators, have an AdministratorsOnly type; if some method can only be invoked in a transaction, have a MustHappenInTransaction type. I find that when you have cross-cutting requirements, types are often the most lightweight way to express them.
    - InfiniteRand 6y ago

by jmull 6y ago

dijit 6y ago

I worked on two very large software projects (AAA games count, right?) and failure to make decisions in a timely manner was one of the largest factors in how much the project suffered, both staff and the product. What I mean by that is, the project which did not decide things on time and tried to save the decision until they knew everything suffered much more than the project which decided in a timely manner and re-evaluated the decision in the rare instance that they were wrong. It was greatly inefficient to have people sitting around not knowing if what they’re working on will even be used because they’re touching something that hadn’t been fully decided on yet, but was required for them to deliver on something else which _had_ been decided. It is sometimes better to decide, iterate and reevaluate. Instead of attempting to defer a decision.

maerF0x0 6y ago
Analysis paralysis (refusing to make a decision until more research is done, to the detriment of a project) is a different error than delaying a decision until beyond the last viable moment.

lmm 6y ago

> There's also work where it makes no sense at all to do while looking ahead at most only two weeks. > For instance, if you have a good experienced architect, a small amount of time spent on a high-level arcitecture will pay you back on even a slightly successful project. Not to mention it will increase your agility. E.g., don't design a sophisticated privilege mechanism until you know you need it. But if there's a reasonable chance a privilege mechanism will be important in the future, know where one would fit in in a way that wouldn't require a substantial rewrite. Now you'll be able to slot in a simple privilege mechanism, if/when you need one, and later replace/evolve that with a sophisticated one, if needed, all quickly and without substantial rewrites. No. This is the most seductive myth in software development, and it's exactly what Agile exists to avoid. I've worked with experienced architects. I've worked with very intelligent architects. I've worked with extremely highly paid architects. None of them ever managed to add value to the project rather than subtracting it. Write the simplest thing that might possibly work. Write plain code that's easy to refactor. Ensure that your test cases (or better still your type system) capture your business requirements so that you can refactor fearlessly and mercilessly. And as if by magic, retrofitting that sophisticated privilege mechanism will turn out to be easy, because you don't have a bunch of architecture getting in your way.

aksjfnkajsnd 6y ago
> (or better still your type system) capture your business requirements How do you mean?
- lmm 6y ago
  Create types that express the requirements that you have, and use them to ensure that requirements are always met. For example, if some fields should only be accessed by administrators, have an AdministratorsOnly type; if some method can only be invoked in a transaction, have a MustHappenInTransaction type. I find that when you have cross-cutting requirements, types are often the most lightweight way to express them.
  - InfiniteRand 6y ago