Developers often justify attention to quality by justifying through the need for proper professionalism. But this moralistic argument implies that this quality comes at a cost — dooming their argument. The annoying thing is that the resulting crufty code both makes developers’ lives harder, and costs the customer money. When thinking about internal quality, I stress that we should only approach it as an economic argument. High internal quality reduces the cost of future features, meaning that putting the time into writing good code actually reduces cost.
Your 6 person team with a consistent autodeploy loop would take 24 people…
32:00 There is a new activity — creating, maintaining, evolving the suite of automated tests. If you went to your manager right now and said please can we invest 23% of our budget in test automation what would your manager say? That’s a rhetorical question. Yet here we have the business case of doing that. Despite you have 23% of your budget in test automation, that has enabled an 8x improvement in cost spent on innovation. It has massively reduced the amount of non-added value activities we are doing. Lean works by investing in removing waste so that you can increase throughput. … Here is the number to take to your CFO
These content should be enough. Crash courses are not recommended. Git is a technical tool with a bad UI. It requires users to have an accurate mental model of what it is, if not it will be used like Dropbox and people lose sleep.
It’s free. Chapters 1–3 give you a history of version control systems and a short intro on how Git works.
Great explanation on git internals and data structure.
git checkout . …
25:00 A lot of these architectural refreshes focus on the exciting new technologies but not on the outcomes that we are trying to achieve. Our research is very clear about what you should be aiming for with your architecture. We found that people who had answered yes to these questions were much more likely to be able to succeed at continuous delivery and devops and achieve high levels of performance.
The important thing about these outcomes is you can do these stuff with mainframe systems. Equally you could buy all the finest new technology and use kubernetes and docker…
We have the wall of confusion at scale between these communities or in the organization. So what we decide in some places is we are going to take the dev and ops divide and the wall of confusion and we are going to solve it with a new silo.
11:14 That’s the reason that we want to do fast cycle time. It’s because we want this early information. We want the ability to scratch the first number off and see if we are on the right path or not. It’s actually worth paying more money than we would instinctively think to get that degree of information. That is why we want a highly efficient and technical organization. What a good technical organization looks like from the outside — it’s an organization that can give you rapid cycle time. It allows you to take ideas, quickly put them into production, see whether they are working and then be able to pursue, switch or do the rest of it.
“A late change in requirements is a competitive advantage”
- Mary Poppendick
You see more sophisticated agile teams focusing a lot on things like cycle time — we are able to change things very fast. Of course this makes success a lot more complicated to measure. Success is no longer going according to plan because the plan changes every week. How can you base success on that? Instead you have to base success on things like business value and are we actually improving, .. are we more efficient as a whole …. It is the responsibility of everybody involved in the organization. It’s hard to point fingers around … It’s still true, if you measure success based on on time and on budget you’re missing the key point of what agile is about.
Not starting features before there’s CI. I’m a strong advocate for this. With open source/ free/ cloud options — Github, Docker there is really no excuse. It’s relatively easy to set up, cheap. The later it’s delayed the harder it is to figure out from scratch. With the environment set up, there’s less friction in writing code that’s testable and refactoring.
The PR is merged! https://github.com/aljorhythm/sapere-server/pull/2. Here is a journal of the decisions and lessons learnt. Some of these are documented in the changes of the PR.
The repo effectively has CI, and can be slowly evolved. On branches where…
There’s much unfounded fear surrounding merge conflicts. In the non-CI, non TBD world, long-lived branches introduced conflicts which were difficult to resolve and led to the very mistaken view that to manage these situations, changes have to be isolated from each other carefully. In reality this raises even more problems.
On the other hand I’ve seen the notion that frequent merges are made to avoid conflicts. It’s actually the opposite. Just like real life, conflicts are a reality and unavoidable. The total impact of conflicts is not reduced by delays — that’s wishful thinking. …