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.
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.
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!
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!
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.
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.
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).
A call-to-arms for web developers combined with a handy list of projects you can get involved in.
Ariel talks about labours of love; pico projects; £5 apps; call them what you will.
This looks wonderful: "a directory of ways to participate in space exploration." I'll be keeping my eye on the Elevator:2010 project.