4 ms·

> Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work This

> Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work This is a really interesting insight. I don't have much personal reference to compare to the software dev cultures in e.g. the 80s or 90s, but there is definitely a shift towards software engineers having more autonomy, more connected with the customers, often being customers of the software themselves.

dkarl 8y ago
I don't know — I came into the software dev world in 2000, and we worked in cubicles and planned in slow waterfall cycles. Integration happened very late in the development process. The managers often wore suits. Programmers didn't talk to clients. In that environment, the old-fashioned processes were still not better than people just making it up as they went along, which is a pretty damning assessment of "decades of progress." I mean, this should be tempered by Keynes' observation that "Practical men who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct [he said economist, fill in whatever field applies]." The ideas came from somewhere. The people who were "just making it up" distinguished between different forms of testing, used some form of project planning, and followed some kind of waterfall process that was internally iterative. These ideas were found in the experts' books. The difference was that the seat-of-their-parts people left out 80-90% of what the experts said was required for a successful software process, and they produced the same quality software faster and cheaper than people who studied the books and followed the recommendations faithfully. So maybe there was an incremental improvement as more and more ideas were crystallized and propagated through the development community, and the experts erred only in their maximalism.

dkarl 8y ago

I don't know — I came into the software dev world in 2000, and we worked in cubicles and planned in slow waterfall cycles. Integration happened very late in the development process. The managers often wore suits. Programmers didn't talk to clients. In that environment, the old-fashioned processes were still not better than people just making it up as they went along, which is a pretty damning assessment of "decades of progress." I mean, this should be tempered by Keynes' observation that "Practical men who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct [he said economist, fill in whatever field applies]." The ideas came from somewhere. The people who were "just making it up" distinguished between different forms of testing, used some form of project planning, and followed some kind of waterfall process that was internally iterative. These ideas were found in the experts' books. The difference was that the seat-of-their-parts people left out 80-90% of what the experts said was required for a successful software process, and they produced the same quality software faster and cheaper than people who studied the books and followed the recommendations faithfully. So maybe there was an incremental improvement as more and more ideas were crystallized and propagated through the development community, and the experts erred only in their maximalism.