5 ms·

i've seen plenty of people that tried to tackle a big problem at once and the result was way more ugly than just split the problem up. at my work place my boss

by merb 8y ago

i've seen plenty of people that tried to tackle a big problem at once and the result was way more ugly than just split the problem up. at my work place my boss always writes down the complete issues/features and let the people do them however they like, but most of the time this is bad, because doing something at once without a certain structure will yield a way bigger mess than if the thing would've been splitted.

wolco 8y ago
That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.
- notduncansmith 8y ago
  There are two primary styles of software development. The first is “make the change/feature easy, then make the easy change/feature”. I call this Structure-Driven Development (SDD), because the features of the software are emergent properties of the structure of the system. This often concerns various “layers” of the system (HTTP, auth, validation, data access, error-handling, etc). The second is “make the change that’s currently easiest”. I call this Feature-Driven Development (FDD), because the structure of the app is whatever emerges from feature development. This, naturally, concerns the various features of the software itself, spread across whatever primitive components are already available and usually copying structure from the first few features written. IMO, successful agile product development involves a mix of these styles. SDD produces better structure at the expense of heavy up-front development costs. FDD helps you figure out where to apply SDD. I like to start projects with SDD for the first few weeks of a project, then alternating styles every 2 weeks to test and refine structural assumptions (think of it like a REPL for architecture). This also helps keep teams from getting too stuck in either style as many do. Get locked into SDD, end up not shipping a single feature for weeks. Especially prone to happening on single-developer projects. Especially unlikely with good project management + strong communication between engineers and stakeholders. Get locked into FDD, code yourself into corners, gradually building a pile of mud that no-one fully understands. Far less likely (but still possible) on single-developer projects. Senior engineering oversight and adequate time budgeting are critical to preventing this. Both styles have their tradeoffs, and like most things it takes experience/maturity and a dash of luck to navigate the balance successfully on a given project. One indicator that your SDD is working is that you do much less of it after the first month or two of development, as the structure will be in place and effort can largely shift to features and polish. EDIT: Cleaned this up into a post here https://medium.com/@hi_17592/software-development-styles-ebea14fdf4bd https://medium.com/@hi_17592/software-development-styles-ebe...
  - beaconstudios 8y ago
    there's also a blended style where you start with FDD then perform SDD in the refactoring. This way you're not performing blind architecture - you make the necessary change and you systematise the solution during refactoring, if it is a change in system behaviour. You can use this technique on an ongoing basis at a per-ticket scale and trust that you are 1. not violating YAGNI and 2. always in a state of minimum-viable-well-designed-architecture.
- merb 8y ago
  > That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own. that's not true. an experienced developer will actually structure the project in a good way, even if the problem is split into multiple issues.
- brazzy 8y ago
  Or it leads to dicking around forever while you change your mind five times about what the "proper structure" is because you're not comitting to anything and not getting any feedback. Experience has very little influence on that.
  - wolco 8y ago
    If someone is playing around trying to get a proper structure it really is a lack of experience. If a person repeated the same project 5 times on the last attempt would require very little trying to find the proper structure. Experience has everything to do with that.
  - defined 8y ago
    "Analysis paralysis" is a real thing, so I partly agree with you. Sometimes you have to take parts of a large concept and "dick around" with it to discover the unknown unknowns and how not to do it, then feed that back into analysis. After a number of iterations of this, you converge on a baseline architecture that you try to support future change without being excessively focused on YAGNI. Over-focus on YAGNI often leads to architectures that are so inflexible that when you DO need it, you can't add it without a demolition crew[1]. People should also remember the context in which YAGNI came up: Kent Beck, Ward Cunningham, Smalltalk, and the C3 project. This particular combination of people, project, and process made YAGNI feasible. And the C3 project, which spawned XP, was not as successful as folklore would have it[2]. It's not always so. Imagine if YAGNI was the focus of Roy Fielding and the HTTP specification, which has lasted remarkably well because of allowance for future change in the architecture. Scrum and other processes that claim adherence to the Agile Manifesto work best in certain contexts, where code turnaround can be fast, mistakes do not take the company down and fixes can be redeployed quickly and easily, the requirements are not well-understood and change rapidly, and the architecture is not overly complex. Many other projects don't fit this model, and people seem to think that so-called "Agile" (which even the creators of the Manifesto complain is not a noun), and mostly Scrum, is the sole exemplar of productivity. The fact is that there are many hybrid development processes, described by Steve McConnell[3] long before the word "agile" became a synonym for "success", that may be more suitable to projects that have different dynamics. An example of such a project could be one that does have well-defined requirements (e.g. implementing something based on an international standard) and will suffer from a pure "User Story" approach. Let's be much more flexible about how we decide to develop, and accept that you need to tailor the approach to the nature of the project, based on risk factors, longevity, and other factors, and not on dogma. And let's not underplay the extreme importance of a well-thought out architecture in all but the most trivial of projects. [1]: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [2]: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... [3]: https://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005 https://www.amazon.com/Rapid-Development-Taming-Software-Sch...

by merb 8y ago

wolco 8y ago

That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.

notduncansmith 8y ago
There are two primary styles of software development. The first is “make the change/feature easy, then make the easy change/feature”. I call this Structure-Driven Development (SDD), because the features of the software are emergent properties of the structure of the system. This often concerns various “layers” of the system (HTTP, auth, validation, data access, error-handling, etc). The second is “make the change that’s currently easiest”. I call this Feature-Driven Development (FDD), because the structure of the app is whatever emerges from feature development. This, naturally, concerns the various features of the software itself, spread across whatever primitive components are already available and usually copying structure from the first few features written. IMO, successful agile product development involves a mix of these styles. SDD produces better structure at the expense of heavy up-front development costs. FDD helps you figure out where to apply SDD. I like to start projects with SDD for the first few weeks of a project, then alternating styles every 2 weeks to test and refine structural assumptions (think of it like a REPL for architecture). This also helps keep teams from getting too stuck in either style as many do. Get locked into SDD, end up not shipping a single feature for weeks. Especially prone to happening on single-developer projects. Especially unlikely with good project management + strong communication between engineers and stakeholders. Get locked into FDD, code yourself into corners, gradually building a pile of mud that no-one fully understands. Far less likely (but still possible) on single-developer projects. Senior engineering oversight and adequate time budgeting are critical to preventing this. Both styles have their tradeoffs, and like most things it takes experience/maturity and a dash of luck to navigate the balance successfully on a given project. One indicator that your SDD is working is that you do much less of it after the first month or two of development, as the structure will be in place and effort can largely shift to features and polish. EDIT: Cleaned this up into a post here https://medium.com/@hi_17592/software-development-styles-ebea14fdf4bd https://medium.com/@hi_17592/software-development-styles-ebe...
- beaconstudios 8y ago
  there's also a blended style where you start with FDD then perform SDD in the refactoring. This way you're not performing blind architecture - you make the necessary change and you systematise the solution during refactoring, if it is a change in system behaviour. You can use this technique on an ongoing basis at a per-ticket scale and trust that you are 1. not violating YAGNI and 2. always in a state of minimum-viable-well-designed-architecture.
merb 8y ago
> That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own. that's not true. an experienced developer will actually structure the project in a good way, even if the problem is split into multiple issues.
brazzy 8y ago
Or it leads to dicking around forever while you change your mind five times about what the "proper structure" is because you're not comitting to anything and not getting any feedback. Experience has very little influence on that.
- wolco 8y ago
  If someone is playing around trying to get a proper structure it really is a lack of experience. If a person repeated the same project 5 times on the last attempt would require very little trying to find the proper structure. Experience has everything to do with that.
- defined 8y ago
  "Analysis paralysis" is a real thing, so I partly agree with you. Sometimes you have to take parts of a large concept and "dick around" with it to discover the unknown unknowns and how not to do it, then feed that back into analysis. After a number of iterations of this, you converge on a baseline architecture that you try to support future change without being excessively focused on YAGNI. Over-focus on YAGNI often leads to architectures that are so inflexible that when you DO need it, you can't add it without a demolition crew[1]. People should also remember the context in which YAGNI came up: Kent Beck, Ward Cunningham, Smalltalk, and the C3 project. This particular combination of people, project, and process made YAGNI feasible. And the C3 project, which spawned XP, was not as successful as folklore would have it[2]. It's not always so. Imagine if YAGNI was the focus of Roy Fielding and the HTTP specification, which has lasted remarkably well because of allowance for future change in the architecture. Scrum and other processes that claim adherence to the Agile Manifesto work best in certain contexts, where code turnaround can be fast, mistakes do not take the company down and fixes can be redeployed quickly and easily, the requirements are not well-understood and change rapidly, and the architecture is not overly complex. Many other projects don't fit this model, and people seem to think that so-called "Agile" (which even the creators of the Manifesto complain is not a noun), and mostly Scrum, is the sole exemplar of productivity. The fact is that there are many hybrid development processes, described by Steve McConnell[3] long before the word "agile" became a synonym for "success", that may be more suitable to projects that have different dynamics. An example of such a project could be one that does have well-defined requirements (e.g. implementing something based on an international standard) and will suffer from a pure "User Story" approach. Let's be much more flexible about how we decide to develop, and accept that you need to tailor the approach to the nature of the project, based on risk factors, longevity, and other factors, and not on dogma. And let's not underplay the extreme importance of a well-thought out architecture in all but the most trivial of projects. [1]: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [2]: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... [3]: https://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005 https://www.amazon.com/Rapid-Development-Taming-Software-Sch...