Glenn Davis of Project Cool’s Cool Site Of The Day from waaaay back in the day is writing his online memoirs.
Depending on when you got online, this will either bring back a lot of memories or sound like something from a different century (which technically it is).
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.
I think that working on your own website can be a good Forever Project.
It’s an open-ended topic that you can explore for a long time without running out of challenges.
Also, this is spot-on:
Compare two different situations where you tell a story at a party. In the first situation, you tell the story in a corner to one or two people, who are totally interested and smiling. In the second situation, you tell the story in the center of the party with a large group of people around you, but they’re almost all bored and uninterested, talking amongst themselves and largely ignoring you. The first situation sounds better, right? Well, that’s the non-obvious benefit of blogging. There are a load of people out there blogging, and almost all of them are better writers and better looking than you. Nobody is going to read your blog about frabulizing widgets unless they really care about frabulizing widgets. So it’s not going to be a big audience, but it should be an interested audience. And I think you’ll find that you get 90% of the benefits of socialization from a handful of readers as you would get from a sea of readers.
A graveyard for good domains you let expire.
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
This gets me right in the feels.
I can’t believe I was lucky enough to contribute to 24 Ways seven times over its fifteen year lifespan!
It’s been an absolute pleasure having Holly, Laçin, and Beyza at Clearleft while they’ve been working on this three-month internship project:
Self Treat is a vision piece designed to increase self-management of minor health conditions.
You can also read the blog posts they wrote during the process:
The title sounds clickbaity, but this is a thoughtful list of project ideas from Chris (partly prompted by the way other lists seem to involve nothing but JavaScript frameworks).
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.