So, going back to pyramids versus honeycombs, when I read advocates of honeycomb and similar shapes, I usually hear them criticize the excessive use of mocks and talk about the various problems that leads to. From this I infer that their definition of “unit test” is specifically what I would…
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…
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…
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 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.