fun
Follow the fun
An Article by Dave RupertAnother great dissertation from Mark Brown of Game Maker’s Toolkit: The Games that Designed Themselves. It’s the radical idea that designers should ignore their preconceived notions and look to the game itself to find out where the development should lead. How does something design itself? Well… the answer is: Prototypes.
A lot of great indie game masterpieces are the result of experimentation and early gameplay demos that changed the course of game’s development. As Brown points out, there’s a whole history of groundbreaking games that were developed “almost by accident” where bugs and glitches were turned into features.
Exit pages
An Idea by Brad EnslenToday I made an Exit page. So many people end their visit by hitting the Back button on their browser. The exit page is a last attempt to get them to explore the Blog Directory to find an entertaining blog. Or failing that to try a search on a search engine they may have never tried before.
The Whimsical Web
A Website by Max BöckA curated list of sites with an extra bit of fun.
APL386 Unicode
A Font by Adám BrudzewskyAPL font based on Adrian Smith's APL385 font with a fun, whimsical look, inspired by Comic Sans Serif.
APL (named after the book A Programming Language) is a programming language developed in the 1960s by Kenneth E. Iverson. Its central datatype is the multidimensional array. It uses a large range of special graphic symbols to represent most functions and operators, leading to very concise code. It has been an important influence on the development of concept modeling, spreadsheets, functional programming, and computer math packages. It has also inspired several other programming languages.
The Taft Test
A Tool by Maciej CegłowskiDoes your page design improve when you replace every image with William Howard Taft?
Party in a shared google doc
An Article by Marie FoulstonIn the absence of the cultural spaces my work usually occupies, I’ve found myself chasing the social rituals they evoke and the reverence they embody through abstract digital recreations and pastiche. In these spaces, familiar feelings and experiences reverberate and mix with new ones.
They are events that all at once feel both practical and absurd.
In a time of such flux and uncertainty, maybe that is as good a place as any to be.
Why we stopped breaking down stories into tasks
The Scrum process says to break down stories into tasks to make estimation easier, encourage collaboration and to be able to show more granular progress during a sprint.
But after a few sprints, we decided to do the next sprint without creating tasks. As a result we drastically increased our velocity and never went back. Here I'll jot down some of the reasons we decided to do this:
- Breaking down stories into tasks is time consuming
- The tasks we came up with invariably would change as we worked on the stories
- Tasks are repetitive
- Tasks were often carried out in parallel
- Our estimates didn't improve
- It decluttered our task board
- It encouraged collaboration throughout the sprint
While we started our process by following Scrum to the letter, we soon realised that breaking down stories into tasks was something that wasn’t worthwhile for us. In the end we realised that it was overplanning and poor use of our time. In the end we used that time to get on with the work and deliver at a significantly faster pace.