4 ms·

If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-orga

• barrkel 11y ago
  You'll get a blob that gets harder and harder to modify over time. For a throwaway system and / or with piles of money, it may work until the system needs replacing. Different people working on similar vertical slices through the system leads to slightly different parallel implementations and probably some duplication of helper logic. Refactoring won't get scheduled and it'll become technical debt in the way all duplicated logic is: not a big deal to start with, but an increasing source of bugs and features fixed / implemented in one place but not another. Inexperienced developers won't be disciplined in keeping their abstractions separate; they tend to intermingle their abstractions so that the boundary is fuzzy. Specifically, they lack layering discipline. Instead of libA using libB which uses libC, they'll pass bits of libA into libB and return bits of libC. When implementing a complex algorithm that joins libA to libB, they'll write code that zips the two together within its convolutions, rather than creating adapters for libA and libB so that the algorithm follows naturally. And they'll model the domain, but nothing much more abstract, and write convoluted procedural algorithms in VerbingClasses (new ThingDoer(x).doThing(y)), possibly with interfaces for mockability. And to be frank, many line of business applications can cope with this. The developers are cheaper and easier to find, and IT was always a cost centre anyway. It's no way to live if you love code, though.
  • blowski 11y ago
    Of course. If we lived in a world where good, productive, experienced developers were cheap and plentiful, we could do things very differently. As it is, it can be more efficient to pay cheap developers to continually patch (or even rebuild) big balls of mud than pay expensive developers to build it properly in the first place. And I'm not going to complain, because I benefit from the current system.
• Silhouette 11y ago
  If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-organise into an effective team, whatever the methodology. I'm sure there is an element of truth to this, but I doubt it's as decisive as you're suggesting in real life. If you've got a good team of expert developers, people who are both individually skillful at producing useful code but also good team players and able to co-operate, I'd say you have a decent chance of them self-organising. I'd omit the "whatever the methodology", because these are exactly the kinds of teams who don't want or need some consultant's pet methodology limiting their options. Of course, there is more to building useful real world software projects than just producing a good design and implementation. Even the most technically brilliant team also needs a clear goal to be effective in practice. Capturing the requirements and turning them into actionable specifications is a significant challenge in its own right, one which requires a very different skill set that even exceptional developers won't necessarily have. I suggest that one of the big differences between a highly skilled and experienced team and a team with more modest capabilities is that the former will immediately recognise the need for clear specs and try to do something about the lack of them. The kinds of development processes and methodologies we're talking about today are designed in part to shield the latter from the same responsibility, but consequently they also rely on having very good people to do that work instead (and by corollary tend to fail hard if the communication with customers and resulting planning work aren't up to standard for whatever reason).