Rachel M. Carmena

Coding-centered methodology

Published: 23 January 2019
Last updated: 31 July 2019

A friend of mine:

Rachel, I’m lost with so many names: Scrum, Kanban, Scrumban, Extreme Programming, Agile methodologies and DevOps. And now you are talking about Software Craftsmanship. Absolutely lost. Where are we going? What methodology should I choose?

It was a difficult question and I needed to organize the mentioned methodologies and cultures.

At that time, I remembered one of the reflection moments that came up when preparing a talk.

I talked about Software as a Craft at the University of Tarragona with a lot of students as attendees. However, I forgot to ask them if the Waterfall model was still taught there and how.

Taking the definition of Extreme Humility as a reference, I came up with these reflections.

Waterfall

There was a lack of humility, because it was thought that we could make each phase correctly one after another.

Developers were not expected to think, because they only had to program what other people thought. And experienced developers were promoted to think and they lose their expertise in programming.

There were also a separation between master (first phases) and apprentice (coding phase), the difficulty in giving feedback and a clear separation with Testing and Deployment phases at the end (quick, quick, we’re late).

Alternatives to the Waterfall model were both the iterative development and the incremental development. Its combination led to new development methodologies.

The idea of Scrum for software development was presented by Jeff Sutherland and Ken Schwaber at OOPSLA conference in 1995. All activity in the Scrum Development Process takes place within two inspect-and-adapt cycles: sprint and daily meeting.

Kanban System was developed by Taiichi Ohno, a vice president of Toyota, and Shigeo Shingo and it consists of a set of cards containing all the information required to be done on a product. They are used to control the work-in-progress (WIP), production and inventory flow.

Scrumban was born as a way to transition from Scrum to Kanban, when introducing Kanban to visualize, understand and continuously improve the way of working.

On the other hand, Kent Beck created Extreme Programming in 1996 and it takes values, principles and practices to extreme levels. As Kent Beck wrote:

(…) there are certain things that you have to do to be doing XP. You don’t get to choose whether or not you will write tests - if you don’t, you aren’t extreme (…)

In 2001, there was a discussion about all the new methodologies and the result was the Manifesto for Agile Software Development. The list of 12 principles include:

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Continuous attention to technical excellence and good design enhances agility.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These 3 principles are focused on professionalism and well-craft software. However, in 2008, Robert C. Martin proposed a fifth value for the Agile Manifesto: Craftsmanship over Crap.

More discussions came up with an extension of the Agile Manifesto in 2009: Manifesto for Software Craftsmanship.

Software Craftsmanship is an approach to software development that inspires me the apprentice/master relationship, professionalism, practice to improve coding skills and the existence of communities.

Finally, DevOps term comes from DevOpsDays, the conference that brings development and operations together since 2009. I understand DevOps as a culture of collaboration and cooperation between development and IT operations, working together towards a common objective.

Coding-centered methodology

So I think that we are travelling to a coding-centered methodology as follows:

  • More humility when postponing decisions
  • More humility when trying concrete experiments
  • More humility when doing small and simple steps
  • Getting fast feedback and embracing change
  • Working together with a better communication
  • Having common objectives as a team (business people and customer included)
  • Having a common responsibility
  • Having a better knowledge transmission
  • Having a set of agile technical practices

And following a learning culture in order to share and improve our skills.

[UPDATE] Of course, coding-centered doesn’t mean only coding, nor to remove analysis and design, but focused on getting value and feedback as soon as possible. As Kent Beck said in an interview:

We were taught that the way that you develop software is you think very carefully about what you’re going to do first (…) you draw lots of diagrams and you write lots of text and you specify exactly what the system needs to do - not exactly how it’s going to accomplish it - and then, you design exactly the computer system that will implement those ideas (…) When you start implementing it, you realize “hey, this is not what we want the system to do”. And even if that is what we want the system to do, the way we were guessing isn’t going to work to make that happen (…) It’s a question of the order of the decisions (…) Nobody’s saying you don’t have to decide what the system has to do, but the question is how much of it you have to decide when.

My friend again:

Thanks, I have a general idea now. And which are the rules of that software development methodology?

There aren’t rules.

It consists of values:

principles:

and practices:

Further reading

Disclaimer

I usually simplify the terms with methodologies or cultures. However, there are more terms as methods, models, frameworks, processes or approaches, among others.

For example, the authors of Scrum called it “Scrum development process” to avoid the method or methodology debate. However, it’s also referred as an agile framework.

In this post, I usually used the terms that appear at the Wiki by Ward Cunningham.

Update: agile anti-patterns

At the beginning of 2018, I got a book for free because of the first version:

It included both common situations with agile methodologies and a lot of ideas to improve them.

I must do something, I thought. I learnt a lot with this book and it would be very useful for product owners, scrum masters, developers, …

I know a lot of friends who are experiencing the problems described in the book. However, it’s in English. I’m sure it would have a bigger impact if it was in Spanish.

So I decided to translate it in an altruistic way.

Here the result:

Thanks David Tanzer again for your great gift.

And thanks José Manuel Beas for your review on the first version of the translated book.

Update: the future of software engineering

I’ve seen this keynote by Mary Poppendieck about The Future of Software Engineering:

She talks about:

  • From Scale up to Scale out
  • Infrastructure as code
  • Autonomous teams (autonomous = independent deployment)
  • The new technology stack
  • The dependency problem
  • Resilience Engineering
  • From defect free to fault tolerant
  • Builing a deployment pipeline
  • End-to-end feedback
  • From delivery teams to problem solving teams
  • A process without requirements, features, estimates or a backlog of stories, based on experimentation and learning: start with signals, focus on problems, plan with hypotheses, do multiple experiments and use data to decide.

Update: notes

From Pragmatic thinking and learning. Refactor your wetware by Andy Hunt:

Programming is all about problem solving. It requires creativity, ingenuity, and invention.

(…) the two most important modern skills are these: communication skills, learning and thinking skills.

Agile methods differ from traditional plan-based methods in a number of significant ways, most notably in eschewing rigid rules and discarding dusty old schedules in favor of adapting to real-time feedback.

Agile development uses feedback to make constant adjustments in a highly collaborative environment.

Avoid formal methods if you need creativity, intuition, or inventiveness.

On a software project, as with an exploratory or inventive project in any discipline, it’s a given that you’ll learn a little bit more every day.

Be comfortable with uncertainty. Agile software development embraces the idea of working with uncertainty. Early on, you don’t know what the project end date will really be. You’re not 100 percent certain which features will be present in the next iteration. You don’t know how many iterations there will be. And that’s perfectly OK: that’s the sort of uncertainty you want to be comfortable with. You’ll find answers as you go along, and by the end, everything will have been answered.

Agile developers do create documentation, but they use a pragmatic filter to make sure the investment in creating any documentation is really worth the effort. It has to have value.