DEV Community: Robert Sweetman

Estimation... Often terrible sometimes harmful

Robert Sweetman — Sun, 01 Sep 2019 12:32:08 +0000

tldr; Estimation can be useful when choosing between items of similar business value. Using story points as a proxy to forecast when a feature or epic might be finished? Utterly useless and a waste of time.

I feel as thought I don't even have the energy to get into this particular debate but since writing this post has been on my to-do list for at least three months... here goes!

This is my understanding of how 'classic' story point estimation for items should be used. In the early days of your 'agile transformation' you'll all be sitting around a table, playing a game with cards whereby everyone talks about an item, flips over their cards and then the consensus view is adopted with some room for challenge (based mainly on the inter-personal dynamics of the group). Rinse, Repeat. There's room for debate, knowledge sharing and discussion.

However this soon becomes a PITA which is time consuming and this devolves to someone 'giving it a number'. Any debate or learning that would have happened about part 'x' of the code base has now vanished.

Now the focus becomes how many 'story points' a particular team can get done or might be able to 'commit to' in a sprint. Let's just isolate that 'commit to' phrase for a moment because it's essentially meaningless. This month I "committed to" getting some exercise every day. I can have all the commitment in the world but there's really nothing underpinning that statement which will ensure I do as I say. Any number of things might come up.

Similarly "committing" to 30 story points in a sprint and then continually failing to meet that commitment, as well as being harangued by the PM or scrum master for failing to hit some arbitrary number, soon leads to a very toxic work environment.

Estimating single items (as story points as some measure of 'size') and then grouping them together as a way of trying to freeze the number of tasks in a week is ridiculously counter productive. Each item you are presented with will likely turn into a task list, removing all critique and creative potential that might mean the problem is addressed in a better way.

Estimates of single items are riddled with the following issues:

People just inherently are terrible at estimating task time in isolation
Huge tendency to low-ball estimates in order to please PMs/Managers
Unknown unknowns, especially around code, are always present
Failing to consider the time needed to write documentation
Failing even more to consider the time needed to write good tests
Peer pressure when making estimates

Management will talk about 'getting better estimates' or having more frequent reviews of items progress during the sprint but neither of these are really effective uses of time.

Where estimates do have legitimacy (and the only place this applies) is when looking at a list of possible items to do. It will be pretty clear, because humans are actually good at this, when items will require more work versus the others. This can be used to inform any discussion around feature, bug or epic prioritization since the value will be apparent and then 'cost' relative to the other items on the list can be used to inform a judgement as to what to do next and why.

Let's take a step back from story points and scrum to see why they exist in the context of time and whether there's a better way. Ideally there are only two frameworks for consistently shipping software: -

Fixed date - "we will ship on a regular cadence" e.g. monthly
Fixed scope - "we have a roadmap and the next release will contain these features"...

I much prefer option 1 and the inevitable response from Sales, marketing and the CEO to option 2 will be... "So, when is the next release coming out?". You should immediately be able to see the issue with option 2. not just because it's a throwback to how software was planned, delivered and sold back in 1998...

Now you've got some sort of 'sprint velocity' which has been painstakingly assembled over time through building a ziggurat of Story Points.

This is now the measuring stick you're going to use to try to map 'n' features which happen to be in a fixed scope release against time to answer the "when is it coming out?" question. And you're inevitably going to get this wrong and developers will feel bad even if you're supper supportive!

No-one likes to miss a target, even if having one is super ill-conceived in the first place.

Fixed date releasing is FAR better than fixed scope for so many reasons...

You don't need story points, you can focus on customer value
You get better at shipping software 'cause you're doing in more often
Requires you to invest in tooling an automation to make your life pleasant
The business knows releases happen on a regular basis and understand why
Testing 3-4 weeks of changes is SO MUCH SAFER than testing 6-12 weeks of changes!

Story points, as required by management, exist for only one reason. An attempt to answer the question from the business of "when?". They're also an attempt to replace communication around the progress of an item (or not) with a number that, at the start of a sprint, everyone can happily agree is "true".

Rather than teach engineers and developers how to communicate better about the state of an item their working on the inventors of this methodology decided to let them pick numbers for tasks, because that's easier.

Let's say that an item is a three... but half way through the sprint some god awful new implementation detail appears which means it's now almost the same amount of work again...

Does the item still have business value? Should it still even be worked on? Well, in the case of fixed date releases it's all about doing the correct, most valuable thing. Time is expansive and it's a real discussion to be had.

In the case of fixed scope (but now everyone wants a date for the next release) it's all about shoving the item in, under pressure, possibly badly or creating technical debt, and still feeling bad about it!.

As someone a lot wiser than me pointed out...

Happiness is all about your expectations.

Adopting a methodology which is effectively guaranteed to fail, where you or others are always painfully aware of your own shortcomings, is a terrible environment to work in.

Let's spend the time we would have spent in countless estimation debates as to whether something is a 3, 5 or 8 learning rather how to communicate and manage people's expectations in the moment when something inevitably slips.

There's a huge benefit in educating the rest of the business and others as to how GOOD software is written. Yes, use a number for relative size of items (and risk) versus customer value BUT never, ever use velocity as a proxy for time.

While we're here, let's not call them sprints. If development is all about naming things, let's rename this. Sprint 114 is daft and self-flagellatory.

Let's say Iteration 114 'cause that's better. It also tells non-developers something about how software is built. It's not a sprint, it's a marathon.

To bootcamp, or not to bootcamp, is that the question?

Robert Sweetman — Mon, 12 Aug 2019 08:59:22 +0000

Asking the right question when problem solving is often the biggest hurdle when looking to achieve a particular goal. The tendency to focus on solutions can quickly drive good sense and creative thinking from the problem space.

Granted, rushing to take action assuages that feeling of uncertainty but ultimately could lead to ending up in the wrong place. So let's first take a step back, figure out the landscape, see what we can learn and look at the options...

What's the landscape?

Firstly let's recognize that there is a pull from companies for development skills and the sheer numbers of vacancies mean that 'traditional' education establishments simply aren't geared up to meet this need.

Anywhere that a demand outstrips supply there's an opportunity for someone to make money. This landscape of scarce supply creates the following conditions: -

Companies with vacancies are prepared to broaden their pipeline.
- Doing this is seen by most of them as a risk initially
- Continued exposure to good experiences may change this perception, but only company by company
Being able to show a portfolio has more influence on hiring.
- Even Comp-Sci grads have to prove they can code 'something'
Recruiters are likely to be adding LESS value than before
- In an arena where the candidate has options and there are fewer of them then traditional recruitment companies are less likely to get paid
- Recruiters work for the company that pays them a cut, not candidates. Sorry, recruiters don't work for you, regardless of what they say.
- I will die on this hill, fight me
Access to training material, code samples, courses is virtually unlimited...
Access to trainers (actual people) is definitely NOT unlimited
- Developers have jobs so their energy goes there
- Academics (in traditional education establishments) often don't have industry experience and are mostly teaching an out-dated tech stack
Employees must (ideally) have experience, can't get a job with out experience, can't get experience without a job...
- Adverts for Junior devs (implying we will train you up) are always over-subscribed
- People hire people like themselves, which makes the diversity problem in tech even worse...

So broadly that's the map of the terrain.

Where are the pain points?

Demand has outstripped supply and there are entities with money who are in pain. This means they're prepared to forgo their usual (tried and tested) approaches and change to meet the new reality.

You, as a prospective developer, want to benefit from the high value (and wages) tech workers have and enjoy the fact that there are a LOT of opportunities out there. Yes, there are gate-keepers but the supply versus demand is so asymmetrical (and will remain so indefinitely) that if you're prepared to do the work the game is stacked in your favor.

Prospective developers have the following pain points:-

Not knowing enough to know what to learn
Having the time and perseverance to suck at something before it becomes fun
No confidence (yet) that you'll be able to land a role, even after time invested
Nobody to ask or talk you through something when you get REALLY stuck
Self directed practice is just HARD and the world is almost built to distract you
It really helps to have a peer group

Your enthusiasm, desire, preparedness to do the work is great. Well done!

It also makes you vulnerable and exploitable. I could really go all dark side here and lay it on thick but I'd simply ask people to recognize that having a burning NEED makes you vulnerable to being led around by the nose. Now you're at least aware of that fact you might be able to participate slightly more consciously than before.

Do prospective employers really have pain points?

Well, I'd say yes and no. If they wait around long enough eventually they'll manage to hire someone but it's clear that if a bunch of roles can't be filled that product/value/feature can't just be magicked into existence. Companies would at least like to not have recruitment as a huge problem. They're prepared to spend money with recruiters, other third parties, referral bonuses etc. for this problem to not be so acute.

Who gets what part of the value?

Also known as the 'follow the money' question.

Traditional education

You pay us for training (only) which may or may not land you a job in your chosen field and we have no real incentive to keep up-to-date. You might benefit from our prestige as an institution. When it comes to Comp-Sci I'd argue this is negligible. If you're white, male, 18-19 and also want to enjoy a further 3 years insulated from the harsh reality of the job market I'd go with this!

Bootcamp

You pay us for training and we 'guarantee' a job but whether it's funded via an ISA or some other financial instrument, the risk is still yours. You benefit from our recruitment network and the fact the Bootcamp is incentivised to ensure there's a good outcome. A positive outcome increases our value and also avoids negative publicity.

As a prospective inductee into this approach (applying to join a bootcamp) your other option will be to 'teach yourself'... If we disqualify a Comp-Sci degree then what we're actually trying to decide between is teaching yourself and joining a bootcamp.

What's the real difference?

Remember, the option to teach yourself or enter the tech world via a bootcamp only exists due to traditional education paths failures. I don't think this is likely to change soon but, whether you go 'self taught' or 'bootcamp' route, you're still going to have to grind through the following: -

Learning to code is hard, takes time and requires you to actually BUILD THINGS
You will need to develop self discipline and perseverance
You will need to carve out large chunks of time every day for months
You will need to follow an actual curriculum leading to building real things
You will have to study specific topics to pass a code interview

These things are common to both paths because this list is basically just the learning bit... Now, this is where things become really interesting...

Here's are some questions you can ask yourself.

"Do I think I will be able to succeed at all?" 'Cause let's face it, you will be the one doing the work regardless of your path.

"Are there aspects of my lived experience, background etc. that joining a bootcamp may not be able to directly help with, and may make worse?"

"Do I believe the 'value add' that this bootcamp offers (peergroup, mentorship, interview contacts, exposure to hiring companies, regular schedule) is worth what I'm ultimately going to pay?"

In the recent debate (Twitter bustup?) and questioning around bootcamps in general and Lambda school in particular there were concerns raised that a VC funded entity was likely to be remiss in their handling of some students, especially those from areas/backgrounds/ethnicities already seriously under-represented in tech.

People wanted to know whether particular stories were true, how 'specifically' Lambda would put safeguards in place to encourage openness and so on.

One thing that puzzled me (and I'll be prepared to admit I might be wrong here) was the impression I got that somehow traditional education, with it's flawed model and all, somehow had an in-built higher moral standard than a for-profit company?... I'm compelled to point out this is garbage.

Still, it was interesting to read.

Hopefully those still reading at this point will see just from the three questions I asked above that the right answer for you, trying to choose, is ... it depends.

It really does depend on you as an individual to decide whether the shorter timeframe to go from zero to hero is worth it. Don't conveniently forget it's market demand setting the destination, you're the engine and the bootcamp is just the vehicle you've chosen to get there.

So, no answer at all then! I hear you cry - and yes. I apologize. By way of compensation for those still reading I'll offer another option...

Do the work, build your own 'bootcamp'

Lets list the things you don't get access to on your own.

A tutor - defined as someone to answer questions when they're stuck, not someone spending hours taking you through work on a whiteboard daily
A peergroup
Mentorship
Career advice/introductions/opportunities

What I'd suggest, especially to those already established developers is that if they'd like to step up and help their prospective colleagues, then there's very little stopping them from doing so.

I reckon one person wouldn't have too much trouble mentoring up to three motivated individuals. Depending on how much time they dedicate then maybe there's some sort of money involved, maybe not. This whole topic rests on managing expectations but I'd guarantee all parties would quickly learn a metric shit ton about themselves pretty fast.

As an aside, ageism is also rampant in tech/recruiting/development. I'd suggest you dyed in the wool devs with 20, coming up on 30, years experience could make a very comfortable retirement indeed helping out the younger generation!

Now, again, this is not an easy option. The goal is to get those participating up to a standard where they have proof they can do the job they're being asked to do. This is both a blessing and a curse. Let's view it as a blessing.

It requires a fair amount of self-knowledge and self awareness of all those participating. It would however get the students access to the top three (previously missing) components in the list above. If they're all switched on the person they managed to work with would have an intro (with a referral bonus) already on place with their own employer.

If it was constructed as a social change endeavor you could have one, then three, then 9 people participating and the structure might truly grow exponentially.

Very difficult to maintain a a moral/ethical core as that happens but still worth striving for. It's organic growth, rather than via a VC steroidal injection.

As with many topics out in the world today, no-one is going to save us.

Political, moral, religious and corporate entities have failed.

It's on us to save ourselves.

I hope this provides food for thought.

As an aside, who am I?
Or the answer to the "under what authority do I speak?" question.

I am in a very fortunate position to have been in a company where I've gone from sales, pre-sales, support, support team lead, project manager, release manager to program manager. I'm 47, hence the shout-out to ageism above. Not looking forward to that I can tell ya!

I basically snuck in the technical back door by moving from project management and teaching myself Powershell while in my former role but I've also benefited hugely from the fact I'm surrounded by some ridiculously good programmers. They're very generous with their time and explanations.

I'm learning Javascript at the moment. Why? Because even though we're in Bracknell (something of a tech-hub outside London) we simply can't find good Javascript Front-End developers... Which should tell you something!

I'm not going to proscribe which option you choose but I thought it was worth pointing out some of the factors at play and that, having broken down a problem into some of it's constituent parts, there might be a way of tackling it that suits you better.

Personally I could very well see myself going down the bootcamp route but (at my age and work situation) it wouldn't make very much financial sense. I am spending a lot of my off-hours teaching myself and it's just brutal. Doing this via a bootcamp part-time wouldn't help me because the challenge for me is not so much 'coding'. It's finding the time/energy in order to practice in order for me to get to a baseline productive level.

I don't have the financial cushion to take 9 months off work and then re-enter the workforce as a junior developer alongside handing off a percentage of my earnings for the next three - five years. But then again I'm not really the target demographic bootcamps are after either, at least that's my impression.

In summary, I've chosen to teach myself. Yes, it will take maybe 2-3 times longer (more?) however it will also mean I've developed more self-discipline and self belief which are traits I'd like to cultivate. Self-awareness and communication skills are hugely undervalued in the tech industry, don't forget those.

I love learning but it's all about time and self-discipline really.