Programming methods

Wise words:

• Silver bullets don't exist. Each project has unique characteristics and, therefore, needs a specific development method.
• Since each project is unique, shelf solutions rarely are optimal. That being so, in order to get to the best software development method, you must design your own method according to the characteristics of your own project.
• To design your own method, learn from all existent approaches, processes, frameworks, methods, and practices.
• Keep it simple at first. Start using it ASAP and improve it based on actual feedback.
• Someone must be in charge of orchestrating everything related to your brand new development method.
• Continual continuous improvement is crucial.

Interview with Grady Booch

An author telling the story of various and his methodologies. Conclusion: they are not worth using.

No Methodologies

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"

SEMAT: do we need one more methodology?

Same story again. Software is engineering, software development is engineering, so we need theory and practice. Look, we have a new theory and practice. And it works well with the methodology used today, Agile.

See previous post, programmers as artisans. When people will stop defining a theory for a practice which is not yet well defined? Perhaps will never be well defined.

And look, software is a different animal. Stop saying it is an engineering.

Also, Major-league SEMAT: Why Should an Executive Care?

The best approach to software development in general

Methods, hype, fashion? See post at Crafted Software.

"... the vast majority of developers react to all these things. It is not just because someone, somewhere wrote a book, recorded a video or gave a talk in a conference about something that it will make that thing right, in all contexts"

See also Does that thing you like doing actually work? Quote: "I am, of course, asking whether there’s any evidence in software engineering"