Forever trying to tame the complexity dragon. Father, Husband, Enterprise Architect, Learner. Opinions and errors are my own. Successes are due to others
🙌 and if you'd like a deep dive into why observability 2.0 all but requires a columnar database, you can read one of my all time favorite articles: https://t.co/hQUZPpEIvz
it's also a clear, engaging piece of prose introducing you to concepts like indexes and data locality.
Say after me...
"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."
...
"Working software is the primary measure of progress."
Everyone should be striving for what Allen puts forward as the PO role. Unfortunately, too many orgs haven't gotten this message. Usually because of
a) lack of understanding how teams work effectively
b) lack of skillsets
c) lack of trust
d) organizational fiefdoms
The product owner's job is NOT to tell the team how to do its work or what to work on. They "order the backlog" but it's up to the team as a whole to decide "who does what, when, and how." A PO is ***not*** a manager. They tell nobody what to do. Their job is to understand the market as a whole, to arrange conversations between the team and the customer (they are **not** an intermediary between the two), and to organize the work by value. That's it. What they do is nothing at all like the old Business Analyst job. They are ***a team member*** who specializes in product development.
Eyebrows raised. Well, it has been 15 years since I sat in a meeting listening to a climate change plan which was "live on Mars" ... I can imagine what horrors appeared in a philanthropy plan ->
I spent 20yrs+ discussing the benefits of test driven development.
I've spent 2wks learning GT - https://t.co/nhhucXKsh7
I've learnt so many lessons on how we are doing things wrong.
We should have been using example driven development - https://t.co/IwRSyyyNzh
dX : How much will AI reduce IT budgets?
Me : See cloud. Not a cent.
dX : ?
Me : You're in competition with others, any savings from existing activities will be spent on new activities in order to keep up. Your annual IT spend will be the same. Jevons Paradox & Red Queen Effect.
This is a great question. Juca is referring to Donella Meadows' "Thinking in Systems," which is a great book. IMO, learning about systems thinking is critical. We are steeped in systems—systems of work, social systems, we build complex systems. ("Software system" is not a code word for a chunk of code, it's a system of interrelated components—some human; some software—that interact dynamically to achieve a focused goal). All too often, the problems in the software we build come from not looking at that software as a part of a complete system. You cannot understand how a system works by looking only at one piece—you have to understand the whole thing. We focus only on the code (sometimes at the microscopic level) or the tech to our detriment. Find several books and videos on the subject at https://t.co/9NarbC3xMF
@davefarley77 Lot’s of candidates, but no code tools and AI developing code are replacing software engineer toil (good) as well as the sw engineering expertise and good practices (bad).
Simply recording a problem does nothing to get a solution into user/customer's hands. Most backlogs are nothing but records of problems, solutions for which will never be built.
Last time it was a support vendor, now it’s an employee logging into a personal Gmail account. I love that one slip up brings everything crashing down at Okta.
I also like the “service account shared password,” which was presumably “solarwinds123”.
Tech debt is the "silent saboteur" holding back organisations. I love that phrase. Every new thing we build today becomes toxic for our future unless we manage it -> https://t.co/FrhOsMrGKi
dX: There is no cloud. It's just someone else's computer.
Me: It's like computers on the internet, innit.
dX: Eh?
Me: It's a joke from my 2010 OSCON presentation ... but it's a joke. Do you have a point?
Your engineering leadership, however -- including directors, VPs, and CTOs -- DOES need to be constantly pressing and holding the line, making the case for real security and not security theater.
* on the customer contracts you sign
* on how you interpret regulations
It's in how you invest in your test suite, audit your platforms, and especially in how you architect your code, such that you can deploy what you're working on without having to deploy the entire world.
It's bringing security considerations into your architecture from day one.
Fundamentally, the point is that we have plenty of evidence to stop blaming regulations and frameworks. It's honestly not their fault. None of them are sufficiently prescriptive that we can pin the blame on them.
It's entirely in how we choose to interpret those standards.
@ealexhudson@mipsytipsy To quote:
"a) initiating, approving, and executing a change"
The developer 'initiates' via a code review, someone else reviews and 'approves', the CI / CD recognizes the approval, merges, and deploys (i.e. 'executes') the change.
All requirements are satisfied.
A lack of diagrams is one of the reasons that so many teams struggle with creating a technical vision/roadmap, communication, architectural refactoring, onboarding new staff, etc.