I don't see how you can design a complete architecture before you start building. The simplicity principle is at play here. At any given moment, the system has exactly enough architecture to implement the current set of stories. 1/5
The architecture evolves incrementally as the system grows. Any up-front architecture based on guesswork will be bloated & overcomplex. That unnecessary complexity adds expense—everything takes longer, and you need to maintain things you don't need. 2/5
You must know exactly what's required to avoid that, and you don't know that upfront. Also, let's say you spend a year designing before you start building. The thing you design will be obsolete before you've written a line of code. 3/5
The FAA had precisely this problem when it hired IBM to create a new air traffic control system. Every year, they designed a system but never built it because new requirements and tech had emerged during the past year, so they started over. 4/5
This went on for ten years (!) before they just ditched the entire project and did it right. Start simple. Design incrementally. #noxp 5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I've been using @Readdle's Spark email on my phone for years, but they've just lost me with the new big-bang release. Many many changes. Many new features. Utterly incomprehensible. Not as usable. 1/4
This is a great example of why the agile approach of incremental small changes is better than huge releases. Changes come gradually, one at a time, so they're easy to absorb. 2/4
Releasing something that looks like an entirely different product means that you'll lose customers who don't like that new product, and you had no opportunity to get feedback while you were building, so couldn't course correct. 3/4
In a blinding flash, I've had a revelation about many of the people who complain bitterly about mobbing, usually because they identify as "introverts" or as someone with ADHD or on the spectrum. Those are actually not the core issues!
Putting aside the fact that many neurodiverse or introverted ppl & ADHD sufferers enjoy mobbing, it occurs to me that the _real_ problem is they work in a command/control org w/o psych safety, and they can't leave the team. They believe they'll be forced to mob!
Those teams are NOT self-organizing (and not agile), of course. Similarly, at the other extreme, any org that's doing compulsory mobbing isn't agile. Compulsory anything isn't agile. People over process and all that.
The QT is actually a big question. UX and (UI) design are both handled by having UX skills on the team. You "research" by building small, delivering, & getting feedback. Architecture (which is also design) is done incrementally by the team as it writes the code. 1/4
Align with other teams using something like Spotify's guild system (e.g. UX and Architecture guilds). A single Architect or UI/UX expert who works with multiple teams can also help. 2/4
SMEs are a mistake. Talk to actual user/customers, not someone who was a user once upon a time but is probably out of touch with the current needs of actual customers. 3/4
1/ Was asked "what do you mean by 'thin slicing'"? I work from stories. A "story" is a description of a user's problem. It describes the user's work, not ours. We come up with a solution as we implement it and get feedback from them.
2/ A full-blown solution is often way too big to implement in an Agile way, however (i.e. 1 or 2 days max). We need feedback and can get it only when we work small. So we "narrow" or "slice" the story to make it smaller.
3/ Every one of those narrower stories, however, is an end-to-end solution to a subset of the problem described in the bigger story.
One of the problems with PR-triggered code review is that you can go for days (or weeks) w/o getting feedback. 1/4
Since the rest of the code is evolving during that time, merges are difficult, & rolling back work or fixing problems can be a massive effort—much more so than it took to write the code. 2/4
Agile ways of working are based on short cycles, getting feedback, and adjusting. The shorter the cycle, the better. With collaborative methods (ensemble/pair), that days-long cycle is reduced to minutes or seconds, and changes effectively require zero time. 3/4
So, let's talk about secure hashes and passwords (Based on an earlier convo, they are not well understood). A hash is a fixed-width number that you generate by feeding characters into an algorithm. 1/9
The width of the hash is the same (typically 32-64 bits == ~8 bytes, but they can be as large as 512 bits, depending on the algorithm) regardless of the number of characters you feed in. Passwords of any length create the same-width hash. 2/9
(A simplistic algorithm is to just xor the characters together to yield a 16-bit hash. DO NOT DO THAT for real because it's too easy to crack, but you get the idea). Hashes are very efficient to compute, using simple operations (xor, shift/rot, &c.). 3/9