Agile Software Craftsmanship by Uncle Bob
At CrewNew the book “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin aka. Uncle Bob (€27.19 with this URL) is the Bible we get everybody to read when they join us. Before we ship the paperback, we ask our developers to watch on YouTube the 6-part lessons. Not suggested to watch in full unless you are a programmer. Uncle Bob explains well why it is super important to write clean code and how the cost of developing new features will extensionally grow when programmers leave a mess in the code. See in the below image how the hours of work needed (to develop the same functionality) changes as time passes:
Shortly, always refactor your code and name your variables, functions, classes etc. properly so everybody understands your code with a minimal amount of comments. Also, utilising TDD (test-driven development) is a must! And pairing — pair programming (Pairing Guidlines — Uncle Bob & Pair Programming — AgileAcademy) is highly suggested because the proper code review takes the same amount of time as a pairing. I will be writing about this great book longer in the future but let us now move on to the main topic I want to write about today: Agile development.
Agile vs Waterfall
From the above-mentioned 6-part lessons I highly suggest this particular part below to watch by everybody who deals with any kind of software or programmers (product owners, project managers, CEOs, but also developers ):
First, Bob explains how the waterfall software projects can be managed: “Badly”, by “Hope/Prayer”, with “Great Difficulty” and/or by “Dictate and Motivate.” Obviously, these methods don’t work and end up producing the wrong product, a low-quality product, being late with the end result and/or working 80h weeks. That’s mismanagement, not a development problem! That’s the reason why we use agile — because agile gives us the right information early. Agile tells you early how fast actually the features will be completed so you can re-prioritise and re-estimate everything after every sprint (usually 1 or 2 weeks). And thus make better decisions. There’s no software development project where every functionality is in detail known from the very beginning not to speak about when and how exactly it will be achieved. Initial analyses and estimations are a lot of speculation forced on the salesmen by the high competition in the market.
Speaking about the salesmen, another reason why waterfall methods don’t work is greed. Managers and salesmen want all four from the following list of four qualities but you can pick only three. Or give up a little from all of them or any other combinations. That’s a fundamental law of any project (not just a software development project).
- Good quality (working well and not insanely expensive after some months)
- Fast time to the market (get it done quickly)
- Cost-effective (cheap to start / cheap after some time)
- Done (get all the functionality actually completed / usable)
If you’re a startup and need quickly the MVP done before rising the next investment then you can drop the “Quality” and once you get proven the market fit and get the £€$ investment then you can refactor most of it and buy the “Quality” later. If you can’t drop the “Quality” then you need to drop either “Done” for some of the functionality that you don’t need right now or the “Fast” or “Cheap”.
Due to high competitiveness in the market, there will be tons of providers hiding that they trade off the “quality.” Market research shows that mostly from Asian countries but messy code exists everywhere, really. Not that honest or just with poor skillset programmers will deliver you cheap’n’quick something that looks like it is working and after some months when you want a tiny small feature, uptade some dependencies or make some changes then you’ll be told “Aaaarhh, this is gonna take now a lot of time to do it. Better do not touch this — this card house is somehow standing right now. Don’t touch it!” Then you will ask some other company/developer who will look at the code and tell you WTF, WTF, WTF is this SHIT?!
So you have to make sure the code is high quality. If you can’t do it yourself then you have to hire a separate senior developer who will be doing the code reviews for you so you get the bad news early! Well, actually you need to do some code review even before hiring your developers. So, you have to find a balance between speed and cost. You can cut down the speed by doing a lot yourself from your free time (if you’re a programmer or utilise No-Code solutions). Or hiring slightly cheaper freelance programmers working some hours per week after their daily job.
You have to make compromises and adjust the knobs in the below radar chart. Give up a little in everything or just pick three out of four as Uncle Bob suggests.
I coded a simple app here to set your goals here: crnw.uk/calc Move the knobs to define the optimal outcome considering the needs, budget and time you can afford to wait. Also, click on the samples at the bottom to see some typical scenarios from real life.
How agile differs from the waterfall?
Agile — set the goals (cheap/fast/quality/done), prioritise all the features (user stories/cards) and plan just the first sprint. After the first sprint, the results will be deployed and everything will be re-estimated, planned and ordered. Everything is in the change. Feature requirements can be changed after every sprint and you can always decide to leave something out and add something else in. The final outcome may be totally different from the original plans but you will be getting the best possible outcome (that maximises all four qualities).
Waterfall — first there will be the analyse process eg. a couple of weeks or months depending on the size of the project. Once that is done because the deadline is met and it is not possible to measure when the analyse (or design) is “ready” anyway. They are subjective tasks not like development where it can be clearly defined what means “done”. Sometimes customers/managers don’t even see the need to spend any money on the analyse part at all. They think that the poorly written single-text document is just fine and that the analyse is “done” already. Well, then it is pretty sure that the product will be total crap but let’s assume analyse is done.
Once the analyse part is “done,” the requirements get frozen and often EVERYTHING needs to be estimated. Even before the design part has been started😄 OK, now the design part is started and again some fixed amount of time the designer will improve and finetune the UI and maybe also the UX and when the deadline arrives the design is “ready.” Now, most probably during the design part lot of requirements have been changed. Developers must now spend an awful lot of time re-estimate EVERYTHING. The estimations most probably increase a lot because analyse didn’t write down tons of things that the designer was asked to add and draw once the product owners started seeing what it all looks like (and re-analysing).
Do the requirements change?😄 Of course, they change! It’s software, remember. We want the requirements to change! Every software team that freezes the requirements, makes a terrible mistake. We don’t want the requirements to freeze. We want the customers to change the requirements AS SOON AS THEY KNOW WHEN REQUIREMENTS NEED TO CHANGE — Uncle Bob
Agile does not make you go fast (doesn’t slow you down either) — agile gives you data and tells you early what is the reality and what exactly in what quality and when can be delivered so you don’t have false expectations and can make the right decisions after every sprint.
To be continued…
