There is this legitimate, real tension between planning and action, between BDUF and winging it (in extreme cases), between roadmaps and evolution.
I don't think it's "enlightened people vs dumb clods"
If people don't agree on what they're doing together, then they tend to not have a solid, cohesive collaboration.
When is this agreement reached?
Let's assume that there is a problem big enough for many people to work on it.
For them to work independently async, they need to have a very solid agreement up-front so that they don't work at cross-purposes.
It will be a constant complaint that any agreements and documents shared up front won't be complete enough, or won't be accurate enough, or won't be clear enough, etc.
There will have to be alignment meetings often, and if there isn't enough CI there will be many merge conflicts.
The other side of it (not predesign) is to work on all the parts together and integrate continually/continously.
This requires constant communication - every work session is part meeting, part validation, part cocreation.
Two disasters:
* asynch work style without pre-design and alignment meetings.
* collaborative, low-predesign work without constant communication
There seems to be a balance issue here.
The more available the expert on the feature is, the less they need to pre-document and pre-split the work.
The more available team members are to each other, the less pre-design and alignment meetings they need to maintain alignment.
When people aren't available in the flow of work, the more they need a fully-competent/comprehensive document or a fully-competent/comprehensive proxy to stand in for them and answer all the questions they might have otherwise answered themselves.
In either case, though, some kind of chartering of the initiative/epic/feature is needed in order to create initial alignment. We need a shared intention if we're to make a difference: what problem it solves, what success looks like.
It can be a problem to solve and not much else, if we're all cocreating the solution. It requires communication in flow rather than a formalized and divided specification up front.
Comprehensive documentation vs collaboration, think of it as a slider: you have to find the right level, because wherever you put that slider determines how your team works and which set of risks and failure modes are constantly in their way.
If you set it according to how your team currently works, you're ensuring that they work that way.
It's a driver as much as an accommodation.
If you move it, the team moves accordingly.
Waterfall skewed (necessarily) toward pre-worked, comprehensively documented/contracted solutions, and individual work assignments.
Agile skews toward robust communication, feedback, co-creation, and evolutionary design rather than upfront planning.
ISTM that middle ground would have to be light up-front agreements + evolutionary groupwork. Charter and swarm?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I got my new UPS today. I intend for it to supply my internet gear (modem, router, mesh, storage).
I plugged it into the wall, plugged everything in.
Note: this could have been planned better - some of my cables are too short so I need a higher shelf for the unit, but we worked through that.
Everything is working okay... or so it seems.
Plugging every item in one at a time helped me ensure I have all the right cords to the right things. This is rather like industriallogic.com/blog/test-driv…
The name is key here. What is this object for? Why would anyone look for it, or use it? When I'm programming, and I need a skiplist where can I find it, and what is it called there? What if it's not called skiplist?
Sometimes this is simple, like python 'datetime' contains 'date', 'time' 'datetime', 'timedelta', and more.
The name 'date' is scoped, so the name is really 'datetime.date' which is important to realize.
Readability is a relationship between an artifact and an audience, and we all know that. It's not just the artifact, but here is a funky example.
I got a great new overdrive pedal for Christmas. It looks like this:
The weird bit is that usually the bass/treble EQ controls are together, and the volume/gain controls are together.
This time they're not and that was confusing to me.
Why such a weird order?
so, OO, right?
What people are doing with Java typically is nothing like OO.
Imagine you're creating your own language specific to your problem domain and solution domain.
That's a beginning.
A language in which you can solve your problems in your domain and stack.
It doesn't exist, btw. Java, JS, Python, C#, Smalltalk -- they're not it. They're the language you build your language in. You don't implement the solution in Java. You implement your solution in the language you've built in Java.
The problem is that you have two locations in space, a bunch of roads, and you want to route a path from one place to the other.
Don't do that in ints, strings, functions, and doubles.
Do it in places, paths, and routes.
In other countries where you drive on the left, the rule is "say left except to pass" and this works. In the US (where we drive on the right) we don't do that. Cars are in all the lanes. There IS a system though.
The far-right lane (remember we drive on the right) is the "ramp lane." People are always slowing to get off the highway, or coming on slow and speeding up.
You'll be always accelerating/decelerating there, so don't drive this one. Go left.