- Humans can not accurately describe what they want out of a software system until it exists.
- Humans can not accurately predict how long any software effort will take beyond four weeks. And after 2 weeks it is already dicey.
- Tech is dominated by “true believers” and those who tag along to make money.
- Politicians seem to be forever gullible to the promises of tech.
- Management loves promises of automation and profitable layoffs.
But it seems that the sentiment might be shifting, even among those predisposed to believe in “AI”, at least in part.
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.
I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.
Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.
Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.
Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.
A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.
Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.
It’s always humans.
Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.
The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:
- Reusing good software is easy; it is what allows you to build good things quickly;
- Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
- The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.
Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:
- Start as simple as possible;
- Seek out problems and iterate; and
- Hire the best engineers you can.
Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!
The use of React complicates front-end build. We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
The story of Jack Garman and the 1202 alarm—as covered in episode two of the 13 Minutes To The Moon podcast.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
I got a preview copy of this book and, my oh my, it is superb!
If your job involves dealing with humans (or if it might involve dealing with humans in the future), you’ll definitely want to read this.
I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
A really excellent piece from Derek on the history of community management online.
You have to decide what your platform is for and what it’s not for. And, yeah, that means deciding who it’s for and who it’s not for (hint: it’s not bots, nor nazis). That’s not a job you can outsource. The tech won’t do it for you. Not just because it’s your job, but because outsourcing it won’t work. It never does.
Some ideas on the best of use of time in sprint zero of an agile project.
- Understand your context
- Identify risks
- Understand the business process
- Get testing infrastructure
- Understand quality attributes
- Get to know the people
- Prepare an initial product backlog
- Build a walking skeleton/spike
- Build a learning backlog
Agile itself provides us with the ability and opportunity to correct course, it allows us to steer, but it does nothing as such to help us steer correctly.
This observation about (some) agile projects is worryingly familiar:
I was suddenly seized by a horrible thought: what if this new-found agility was used, not teleologically to approach the right outcome over the course of a project, but simply to enshrine the right of middle management to change their minds, to provide a methodological license for arbitrary management? At least under a Waterfall regime they had to apologise when they departed from the plan. With Agile they are allowed, in principle, to make as many changes of direction as they like. But what if Agile was used merely as a license to justify keeping the team in the office night after night in a never-ending saga of rapidly accumulating requirements and dizzying changes of direction? And what if the talk of developer ‘agility’ was just a way of softening up developers for a life of methodologically sanctioned pliability? In short, what if Agile turned out to be worse than Waterfall?
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
A great round-up of Leading Design—one of the best events I attended in 2017.
A series of posts on the decisions and trade-offs involved in being a tech lead:
I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.
If you’re a project manager anywhere near Brighton, put this event in your calendar for the morning of May 30th.
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.