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-Dri

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...