purpose
One of the biggest problems that face developers today is estimating the time required to complete a task.
This is a safe statement to make because there are so many systems you’ve probably heard about which attempt to solve this problem directly.
While working in scrum, developers are not good at estimating timelines, but are good at saying which of two tasks are harder
One of the Basecamp ideologies is that you have a cycle, and the work for that cycle is downwards flexible - meaning if it can’t get done in a cycle, maybe it just isn’t worth doing, or maybe you do a smaller version of it that satisfies fewer requirements etc.
These are things designed to relieve the stress for creators, because it can be super demotivating for someone when they go down a rabbit hole and get some really awesome work done, only to find out that the amazing thing they just made is being overshadowed by the fact they haven’t finished the complete list of tasks they were assigned.
hypothesis
Although I think it’s true - it’s hard to guess how long these will take, you can’t ignore the immense evidence that there are a tonne of agencies that are running even a few years later. The only way this is possible is if they’ve managed customer expectations really well.
Diving a bit deeper into this idea, maybe a complete project isn’t quotable, but maybe individual components are.
A few examples of projects I think would be appropriate to measure would be the following
- change the branding
- Add a new CRUD model to an application
- Add a rich text editor to an application
I think once these are documented, I should be able to get 2 solid pieces of information from this expirment.
- a rough estimate of time for a chunk of a project
- how planning impacts the time for a project - (eg. more planning = less dev? how far can we take that?)
experiment
- Over the next few months, I will document how long it takes me to perform small projects (< 1 day expected work)
- I will detail the type of foundation each project is being built upon, and the requirements for each project.
- I will explain the types of files I’ll be creating (controllers, components, views, models, db tables, migrations, helper files, integrations etc)
I’m going to be using a template like this
- intro - what the project is built on, what foundation we’re working with, what stack etc.
- reqs - project requirements (user stories, general requirements etc.)
- steps - an outline of the project
- BACKEND//PLAN - long form plan talking about data models, integrations, helper functions, policies, etc.
- BACK-END//TODO - summary of files/functions/tasks within this project
- FRONT-END//PLAN - long form plan of views/front end components
- FRONT-END//TODO - summary of files/views/components for the project
- PROJECT//TODO - summary of mini-tasks for this project
- worklog - a table of time taken for each part of the project
- outcome - note, pictures, etc from the project
observations
Coming soon
conclusion
Coming soon
Check out my first worklog here