Had a chat recently with a colleague and the topic of Software Development Lifecycle (SDLC) came up. Whenever I talk about concepts or technical stuff with other people, I typically try to explain it in a way that is easy to understand for a non-technical person. It is a way of challenging myself cos if you can’t explain something simply, it means you do not understand it well enough. One of my favourite approaches is Concrete, Pictorial, Abstract – e.g. if explaining fractions to a kid, use a real pizza first (Concrete), followed by diagrams (Pictorial) and finally concepts (Abstract).
There’s a lot of good articles on SDLC, far more comprehensive than what I can muster, so I’m not going to try to come up with a new SDLC concept. Instead, I’m going to talk about a method I came up with, and try to apply it to SDLC. I’m sure others would have thought of something similar before, just that I’m too lazy to Google for related articles lol. I call this method the Pólya-Kipling Method.
Pólya – Understand, Plan, Do, Check
The first part of the method is named after George Pólya. He wrote a book published in 1945 titled How to Solve It which talks about a system of thinking which can help you solve any problem. This system is his famous Four Principles of Problem Solving – Understand, Plan, Do Check. One of my Math lecturers used to drum this mantra into our heads and it is still ringing in mine after more than a decade 😛
Kipling – 5W1H
The second part of the method is named after Rudyard Kipling. He wrote a book published in 1902 titled Just So Stories for Little Children. In it was a tale, “The Elephant’s Child”, which contains this poem:
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
These are the Five Ws and One H (5W1H) frequently taught to students of English in primary schools – Who, What, When, Where, Why and How. While he may not have been the first one to come up with them, he certainly made them memorable 🙂
The Pólya-Kipling Method
This method is designed to be easy to remember and simple to apply. It has 4 main stages, which corresponds to Pólya’s Four Principles – Understand, Plan, Do, Check. In each stage, the Five Ws and One H are used as guiding questions. And now, let’s try to apply it to SDLC. The context is that of a new feature request for an existing software product. The software is split into several components (backend API, frontend UI, Android, iOS, etc.), each undertaken by a team of developers and a team lead.
Understand
Who: Who is involved? Client, Business Development, Project Manager.
What: What are the requirements?
When: When is this due?
Where: Where in the software are changes needed?
Why: Why is this feature needed?
How: How to measure results?
Plan
Who: Who is involved? Project Manager, Team Lead for each affected component.
What: What are the changes for each component?
When: When are the tasks for each component due? When to do testing and integration?
Where: Where in each component are changes needed?
Why: Why are the changes needed?
How: How will all the components integrate? Architecture, API, workflow.
Do
Who: Who is involved? Developers.
What: What are the tasks and tests for each component and developer?
When: When does each task need to be completed?
Where: Where in the code needs to be changed? Where to commit the code? This can also refer to which stage the task is at – research, in progress, review, QA, done.
Why: Why should a certain design or approach be adopted?
How: How best to code? How to commit code? Tests, best practices, PSR for PHP code, Git flow methodology for committing code, etc.
Check
Who: Who is involved? Team Lead for each component, Project Manager, Business Development, Client.
What: What to check?
When: When does each involved party come in to check?
Where: Where to check? Code, API request/response, UI.
Why: Why did this changed code fail?
How: How to check? Unit tests and linting checks by automated CI, code review by Team Lead, integration testing by Project Manager, user acceptance testing (UAT) by Business Development and Client.
Conclusion
An idea is still just an idea – how well it is implemented in real life is another matter. Obviously, this short exercise does not cover all the possible questions and answers, but hopefully it gives a glimpse on how this method may be used. Try it out today and have fun – adhuc!