Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
200 discarded objects from a dump in San Francisco, meticulously catalogued, researched, and documented by Jenny Odell. The result is something more revealing than most pre-planned time capsule projects …although this project may be somewhat short-lived as it’s hosted on Tumblr.
Chris Ferdinandi is a machine!
A vanilla JS roadmap, along with learning resources and project ideas to help you get started.
Paul was at the Material conference in Iceland too, and we had some good chats. Here, he speaks his brains with Deep Thoughts prompted by the event.
I really get where he’s coming from when he says that “certain websites feel more ‘webby’ than others”, but it sure is tricky to nail down.
Maintaining an open source project is a rollercoaster ride with high peaks and very low troughs.
Release frequency is down. Questions increasingly go unanswered. Issues remain in a triage, unresolved state. Uncertainty and frustration brew within the community room.
Brian’s experience with Pattern Lab very much mirrors Mark’s experience with Fractal. The pressure. The stress. But there’s also the community.
A maintainer must keep the needs of their project, their community, and their own needs in constant harmony.
This is hard!
Here’s a treasure trove of eighties nerd nostalgia:
In the 1980s, the BBC explored the world of computing in The Computer Literacy Project. They commissioned a home computer (the BBC Micro) and taught viewers how to program.
The Computer Literacy Project chronicled a decade of information technology and was a milestone in the history of computing in Britain, helping to inspire a generation of coders.
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?
I really like getting Paul’s insights into building his Bradshaw’s Guide project. Here he shares his process for typography, images and geolocation.
If you’re a project manager anywhere near Brighton, put this event in your calendar for the morning of May 30th.
Incredibly impressive work from the CodePen team—you can now edit entire projects in your web browser …and then deploy them to a live site!
An ongoing photography project from Curtis:
Beyond Work tells stories about humans at work, with no judgement or glorification. It’s an attempt at unearthing the social, cultural and functional world of work, that’s become invisible in everyday life.
I think the move away from side projects toward doing a startup day one is not all good. There was something great about the ability to experiment with an idea before committing to it and before sucking other people’s money into it.
Have a read through all of Remy’s posts on his frustrating—but still rewarding—time running JS Bin.
I’ve always liked testing on the crappiest mobile phones in the device lab—it feels like an honest stress test. I quite like the idea of using a crappy projector for the same reason.
Words of wisdom from Seb when it comes to personal projects: finish what you start.
Most people don’t finish their projects so simply by getting it done, you’re way ahead of the crowd.
Well, this is nice: the Line-mode browser hack has been nominated in the Best Collaborative Project in the Net awards.
But 24 Ways has also been nominated, and let’s face it, that really is the best collaborative project.
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.
David Cole shares the ideas for projects he would like to develop further, but probably never will. I like this a lot (and there are some great ideas in here).