Why don’t software development methodologies work?
An experienced programmer - a "typical" programmer -, one who have used all methodologies and "techniques du jour" shows clearly that methodology is not the key to producing good software.
The text strongly suggests that the key to good software is... the programmer. As a craftsman. Which puts the last nail in the coffin of so-called Software Engineering.
Simple: Software is not engineering. It is related to Art, Craft and Mathematics.See Knuth The Art of Computer Programming.
" I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work."
"My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."
"I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools, and that we should be skeptical of too much process or methodologies that promise to magically make everyone more productive"
Nenhum comentário:
Postar um comentário