How to run a successful development process (even if you’re not technical)
Jonathan Solórzano-Hamilton

You realize that you have described the classic software development life cycle and process, right? It doesn’t matter how much “Agile” sugar you add, in the end working software releases follow the same general process. If you try to leave out architecture and documentation, you end up with a mess.

But this field will insist on reinventing the wheel startup after startup, burning out brilliant minds and burning up years of people’s lives because of some “magic koolaide” that management tells you will “make it work better, faster, less work”, blah, blah — TDD, open plan offices, scrum, ‘sit together’, devops, pair programming, etc, etc, etc.

While some of these work partly, they still need to be paired with a fundamental understanding of software development processes and how people make code into products. If you don’t get those two things, all of the cargo cult koolaide will just make your people miserable and your project either late, sucktastic, or both.

I’ve been doing the operations side of this for nearly 20 years. I’ve watched fads come and go. It all come down to basics:

  • Start: Decide what to do and who to do it
  • Planning: Architect, design, write test conditions
  • Doing: Code & test, inline docs —> if problem, go to start
  • Debug: integration test, bug fixes> go to doing
  • Review: Document, review, acceptance test —> if fail go to start
  • Production/rollback —> if fail go to start
  • Maintenance cycle —> go to start

Yeah, this is a condensed version, but the cycle is there. If you leave any out, it will bite you.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.