Skip to main content

The Harper Lee Experiment

Harper Lee, author of 'To Kill a Mockingbird' wrote the book after a friend gifted her 1 years salary to write whatever she wanted. No-one would argue that that time or money was misspent. It made me think however, when I randomly remembered it earlier in the day about how with some changed variables it could apply to a developer. Then it became a bit of a thought experiment.

Let's say you're random developer with some experience. Not necessarily lots, but enough to be comfortable. On new years eve, a friend (whose reasoning skills you'd likely and understandably question at this point) offers you 1 years salary to create whatever you like under the understanding that after December 31st that this creation would be your livelihood. Through some sort of magic your day job is a thing of the past and you are free to do as you please.

We'll also say as a matter of co-incidence you happen to have been sitting on an idea for some software that a blue box inhabiting man has informed you is a guaranteed hit. You have your idea and 365 days, where do you start?

Getting Started
Well, how much time do you have? That's a good start.

52 weeks - 4 weeks because your friend insisted you take a break.
48 weeks of 5 day weeks, to generalise working for a comfortable 7.5 hours a day.

That gives us a round 1,800 hours of time. It's feeling a bit tight already isn't it? So we already have an idea about the scope of what it might be best to undertake. For example, an application for uploading pictures with captions for your friends to see, that's monetised through some sort of advertising (The requirements stated we have to live off it, remember?).

From there, we can extrapolate a rough feature set, there's going to be some authentication, storage, relationships between user accounts and a phone based UI for your platform of choice. Your at this point unbelievable friend also happens to be a marketing and UI expert and will complete these elements of your work when appropriate to the best of their ability and free of charge, so you can just focus on the software. What's next?

How are you going to manage your workload, Kanban perhaps?
Will you start with the back-end first, the front-end, or develop them in a scenario based format in parallel?
Is December 31st the release day or is that the day you expect to be running smoothly?
Is there beta testing? How long for?
How will you handle security?
What kind of testing do you intend to undertake with your already stretched resources?
How will you know that the service is running smoothly after launch?

You might have a rough plan for what is to be done now to successfully unveil your masterpiece to the world. How does it stand against a few test cases?

Test Cases
1) 3 days after launch your primary chosen cloud platform drops off because of a time-related bug and doesn't return for a day, as a result of this are you missing out on ad revenue or is there a contingency?
2) You decide to take a break for a week, as the sole developer you ask a friend to take the keys to your newly up and running service and keep an eye on it...
    a) Something vague goes wrong and users are sometimes failing to upload photos, can your friend solve it easily and how long did it take them to find out?
    b) That massive new feature you checked in just before you left, it turns out, doesn't work, did it make it through to production and can your friend fix it, and do they even know there's a problem?
3) Generic tech review site X found your app and wrote a front page article about how world changing it is and your user-base explodes like you didn't know was possible, will it scale out succesfully?
4) Someone got into your user database, how bad is the damage? Are they looking at password 'Hunter2' or did you go to some lengths to secure it.
5) It turns out that after your app has been running for 3 minutes it runs out of memory, did you catch it during testing and if not, how long will it take to get the bug-fix to the user?

It's quite easy to underestimate how much time/effort it takes to get something relatively simple to be reliable and the costs involved in doing so. A year seems like a long time until you realise you probably have less than 6 months of product development time when you factor in testing, security, stability, etc. You could just not test it I suppose, and hope that if it falls down your friend isn't too upset about their failed investment...


Popular posts from this blog

Constructing a Trie in F#

This post might get a bit more context next week, but essentially, in continuation of looking at data structures in F# and C# I picked prefix trees (tries) as the next step. A trie is similar to a BST except the search is cumulative. A simple example would be building a spellchecker. The spell checker can use the structure to see if a word exists quickly and efficiently.

It works by creating a new node for each part of the word, using existing nodes if they're already in place. You can see in this diagram an example structure after an insertion of several words.

In the above diagram the words ANT, AND, BATS have been added into the data structure. You'll notice that the word BATS can also be the word BAT and that becomes a part of the structure, setting a value at each node to state if this is a place that a word terminates.

1 2 3 4// Node type for storing a trie. typeTrieNode=|Nodeofchar*TrieNodelist*bool|RootofTrieNodelist
I defined the type to have 2 options. The root node,…

A Docker Experiment

Containers are a topic that have been rising in occurrence for me, for the last year or so. From using them as part of the architecture at work or for various pet projects friends have been working on. I figured it was time to experiment myself and get to grips with what people have been talking about. It seemed like a good idea to find some introductory material that would give me an overview of its uses without delving too far into the details so I could see what it actually was, so I found a PluralSight course about Docker, specifically “Docker and Containers:The Big Picture”. This gave a nice overview of what Docker is, and more importantly what it was trying to achieve and how to use it. With a bit more of an understanding, I wanted to use it for something, preferably something familiar. I decided to try setting up ElasticSearch and Kibana containers, where Kibana would visualize the ElasticSearch data. I used bits of this article along the way as a guide, if you'd prefer a more…

Self-Producing an EP Pt.5: Mixing

After some discussion we opted to mix it ourselves for a few reasons.

It's our first EP, it's not going to be heard by a huge amount of people and while it's important that it sounds good, it's expensive to get done properly and we might be able to manage 'good enough' on our own with a lot of work.Mixing as an online service seems to be the main way to go for small/starting out bands and that seems too creatively detached. There are many stories floating around of people who've sent things off for mixing and the mixer has a much different idea of how it sounds.
Maybe it's not the best choice, but it seemed an acceptable risk that we would at least attempt to have it 'look' how we want and it be a bit wonky than potentially end up with something we're not happy with in a different way. The benefit would have been being able to just ship the stems off and make it someone else's problem instead of weeks of being unsure while swimming in the…