Soon after I started using Stack Overflow to find answers to my programming questions, I noticed the same name answering the questions; Jon Skeet. His “reputation” was really high. So high, it was the highest on the site.
His reputation has become so large though, that it has outstripped his ability, or so he says in his blog on Imposter Syndrome.
I sometimes think that with other aspects of life. For example, can The Beatles be anywhere near as good as their reputation? Surely no band is that good.
It’s funny that Jon even references his Chuck Norris style facts about his ability. The internet definitely see him as a programming legend of the C# world.
I think it’s undeniable that Jon Skeet is an expert. I think the best developers aren’t necessarily the ones with ability, but they also need the right attitude to compliment it. Jon’s support to the community by answering so many questions to aspiring developers on Stack Overflow – makes him an absolute legend. He deserves his reputation.
A bit of a rarity on this blog; time for something positive.
I have been reading the book “Shape Up” by Ryan Singer which can be downloaded free from https://basecamp.com/shapeup
Book Summary
Shape Up defines the Agile Process that Basecamp utilises. The summary at the end of the book lists their ideas as follows:
Shaped versus unshaped work
Setting appetites instead of estimates
Designing at the right level of abstraction
Concepting with breadboards and fat marker sketches (a sketch made with such broad strokes that adding detail is difficult or impossible)
Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
Choosing the right cycle length (six weeks)
A cool-down period between cycles
Breaking projects apart into scopes
Downhill versus uphill work and communicating about unknowns
Scope hammering to separate must-haves from nice-to-haves
There’s quite a bit of Basecamp jargon in there. Some of the sections I didn’t care that much about, but there’s plenty of aspects that seem like they counter many of the problems I have witnessed when it comes to Agile development. So I think this book does provide answers.
Notes From The Book
Some key points that I liked or found interesting (this is basically me copy and pasting from the PDF):
Instead of a traditional two week sprint, they work in six weeks. This time is “long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start”.
They “focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?”
Small Batch : This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle.
Big Batch : This project takes the same-size team a full six-weeks.
They “give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time”.
“Pitches” are posted as Messages in Basecamp software. There are five parts to include in a pitch:
1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
2. Appetite — How much time we want to spend and how that constrains the solution
3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
4. Rabbit holes — Details about the solution worth calling out to avoid problems
5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
“Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks or any pitches that somebody purposefully revived and lobbied for again.”
Backlogs are big time wasters. “The time spent constantly reviewing, grooming and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now”. Pitches therefore, do not go on backlogs. “If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.”
“It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.”
The “Circuit Breaker”: “We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. We intentionally create a risk that the project, as pitched, won’t happen. This sounds severe but it’s extremely helpful for everyone involved.”
it eliminates the risk of runaway projects
it means we did something wrong in the shaping
Dealing with bugs
Use cool-down – the two week gap between the six week cycles
Bring it to the betting table – plan it into the next cycle
Schedule a bug smash – dedicated time usually around downtime like Christmas
Personal Comments From My Experience
So some discussion on why their approach is good:
I found with 2 week sprints there’s a lot of meetings involved for only 10 days work. You end up spending half a day planning, then there are 1 hour meetings like the “Retrospective” that happen at the end of the 2 weeks. With all these meetings, it cuts into the 2 weeks. 6 weeks makes it seem like the planning is less frequent and more worthwhile. You have more to praise/criticise when you reflect on your team’s progress during the retrospective.
Sometimes important bugs become the priority then you end up shelving your work. It would be nice to have the intense focus to ensure you finish what you start.
When we get to the end of the sprint, it is too easy just to move the work into the next sprint, so it makes the 2 week block seem meaningless. Knowing the timing is stricter will put more focus on actually delivering.
Often, bugs that you think are annoying are deemed low priority so they get shoved on the backlog and never fixed. First of all, it would be good to have the freedom to fix bugs that personally annoy you. Secondly, what is the point of having a backlog if it’s just a list of work you know no one will ever address.
A developer wrote some code that tries to extract text that looks like HTML tags. So if you have <h1>, <div> etc in your text, he was basically just deleting the HTML prior to saving it to the database.
The thing is, the code just looked for a “<” then a “>” and removed everything between. So if you had a sentence like “the value is ❤ and >1”, then run that through his code, the returned value would be “the value is 1” which has a completely different meaning. You could have paragraphs of text between these characters, and his code would just delete it.
Not sure why he decided to hand-craft his own solution. There will be more official ways of encoding HTML.
“for those that will be helping out with the Phase 2 testing, the suite is here…”
Becky
I think we have around 5 testers in the team, and only 1 tester responded to Becky. This testing seemed urgent and the fact that she said “for those that will be helping” – this made out it was the testers, plus some other non-testers as volunteers.
As a developer, you assume you aren’t needed – because you’re a developer. But if a tester says their testing is urgent and they need help, then they may request volunteers. It was the first I’d heard of this, and it seemed weird that only 2 people were actually testing.
I questioned the statement, and apparently Becky wanted testers AND developers to volunteer. Why didn’t she say something? She managed to make it sound like people had already been told if they were doing it.
She is so bad at communicating.
Maybe that’s why the Testers weren’t even testing it.
Becky is a Senior Tester and I remember our Team Lead saying he was going to give her more responsibility because she wanted to progress her career. Well, she can’t even manage to get Testers assigned to do some software testing, so what hope do we have?
My manager calls me and says there is a bug that might end up holding the release, and wondered if I can help. He said it was found when testing Colin’s work, but it might not actually be related to his changes.
Colin had been given some other work and he was taking ages on it,so wasn’t available to complete this work himself.
So I call Colin and ask him what this bug is. He sent me the description from the tester (Becky) which was next to useless, he showed me his recent changes, and a specification from his project. Colin assured me that his changes should work, because he just “copied what was already there”.
It seemed like everything I needed, so I got digging into the code and testing it out.
It didn’t take me long before I realised what Colin had done. There were two scenarios that he needed to check. By copying and pasting what he saw in that file; he was just covering one of the scenarios. The other scenario was actually in another file, and he would have realised that if he actually tested it.
The thing is, my first thought was to add a unit test to cover the scenario. I checked for existing unit tests for that file, and there were some existing tests. Colin hadn’t bothered adding additional unit tests; which would have made him realise that his changes didn’t cover both scenarios.
Then days have gone by, the manual testers have finally got round to testing out his changes, and logged this issue just days before the release.
Then I have to save the day once more.
It’s so annoying/stressful when you get given a bug to fix with strict deadlines, but luckily it was very easy to fix. If Colin had shown a bit of effort, then we wouldn’t have been in that situation.
In a previous blog, I was criticising some work done by an Apprentice: Apprentice Insanity
What actually happened with this is that it got deprioritised so was just shelved for a couple of months. Which is weird, because the original developer made out it was very urgent and wanted to check it in at the last minute.
When it was decided it was needed again, who got asked to finish it off?
Yeah! me! What are the chances of that?
The Fix
The work was to show some messages to the user why a feature isn’t enabled for them. There can be several different reasons, but we never told the user why, until now.
So I load up our program with a valid user… I can’t use the feature anymore, and it tells me 5 reasons why I can’t use the feature. It’s completely broken then. A valid user should have allowed me to use the feature, and obviously show 0 reasons.
So I fixed a few bugs, and now I can use the feature, but there are still 3 reasons displayed. So it says I can’t use the feature; but I can, and I know I should be able to.
I spent a lot of time looking through the code, and I saw that there is an existing file that did the validation, but the apprentice had created another file with some other validation rules in. If it is the same rules, then we are checking them twice? If they are different rules, then you end up in a situation like this; where I can use a feature, but the other file’s validation tells me I can’t.
So I end up deleting this extra file, and make the existing file be the code that returns the failed rules.
The new dialog he added looked nice enough, although the dialog was a bit small, and a few aspects of it wouldn’t actually meet our UX standards. When I looked at it, I saw that he had positioned all the controls by hand for a particular size, and so I had to do a lot of rework to get the controls to work on a larger dialog.
He also had code with complicated logic to adjust the size further. Complete hacky. So I got rid of all that too.
There was some other hacky code where he even had a comment along the lines of “for some reason the control can be duplicated, so if this happens, then we need to remove it”. After some experimentation and debugging, I eventually worked it out. What was happening was that the initialisation code was calling his new method twice. You would think that means the control was always added twice, but it wasn’t.
It turns out that there was some existing code that checked if a control was in position 1 in the grid, and if it was; it was then removed. Then there was some logic to re-add it based on a condition. So the control in position one is optional.
Position 1
Control that sometimes gets displayed. Put new control here?
Position 2
Control that is always displayed
Position 3
Another Control that is always displayed
Illustrating the grid layout. There are 3 rows which can have controls in.
The Apprentice was adding his control to position 1 in the grid, but if the other control was there, then he added it to position 2 instead. So what was happening is – if he added his control to position 1, then the existing code then removed it, then when his logic is executed the second time, then it gets added to position 1 once more. So it displays correctly, but works “by coincidence”.
If the existing control is added to position 1, his method then adds the new control to position 2, so when it executes the second time, it adds a duplicate to position 2. So then his hacky code kicks in and removes the duplicate. The simple solution; just create a new row in the grid for his new control. Delete the duplicate call. Delete the hack.
So it seems like he got into a mess by trying to cut corners, put in a hack when it didn’t work, but then it only worked intermittently and he didn’t understand why… so then put in some more hacks to cover it up. What you end up with is nonsense.
In the end, I had completely rewritten it, made the UI nicer, and got rid of all the bugs. Result.
The Demo
We had a demo arranged with someone who was basically representing a user. I was going to demo my code, but, an hour before the meeting, I got an important meeting invite. As a joke, I asked the Apprentice if he could cover me. He said he would be happy to do so. I told him I was joking, but if he really wanted to do it, then it would be appreciated. Like a nutcase, he agreed. With only about 45 minutes to prepare for the demo, I told him I had completely rewritten his code, so he may be a bit lost.
He chose to demo from his existing, broken code.
My meeting turned out to be really short, so I joined the demo as the Apprentice was trying to explain a feature, after it crashed and somehow wiped the contents of an existing dialog, much to the confusion of the Representative.
I saved the day at that point and demoed the proper, working code.
Afterwards, one of my colleagues said to me
“How the hell can you demo something THAT broken?”
A new customer reported a particular feature was broken. This feature used a web browser (Chromium) to work.
A developer spent ages trying to work out what was going on and realised that the site had an invalid proxy script. The invalid script was causing a crash within Chromium, rendering this feature completely unusable.
Due to a typo in their proxy script, their proxy wasn’t blocking access as described by the script; it was basically “anything goes”.
The developer told them how to fix it, and we thought it would be case-closed. However, now that the proxy blocked access to websites as defined by their IT department, their employees started complaining.
Instead of the IT department:
tweaking the rules,
Disabling the script completely
or simply informing their staff that these sites were blocked according to their company policy
They decided to revert back to the original broken script. This obviously made our software break again.
Really, it was a problem with Chromium, the software used in Google Chrome and now Microsoft Edge. Obviously, the workaround is to actually set a valid proxy script, but they decided to be awkward.
When a serious bug is found, there’s all kinds of managers that have a call to discuss it, along with some representation from Development – so at least one Developer and preferably a Tester too.
I got asked to join the call, and there’s like 8-10 people on this call. The representative from Support has roughly described the bug, and how often it has been reported.
Then there are a few managers bickering if the Major Incident is a Medium or High severity. The thing is, we all know it needs fixing urgently, and from my point of view, it doesn’t matter what severity they actually give it. Maybe the managers care because it depends who they have to notify and follow a different process.
I just know that I need to fix it as soon as I can.
However, while the call is going on, this is time wasted because a developer isn’t looking at it. I had been told there was a bug in a particular area, and I know I’ll be the person trying to fix the issue, but I cannot start because I’m on the call. I could multitask, but I wasn’t given the stack trace or recreation steps, so I was left waiting. It would be hard to concentrate if I was half-listening to the call too.
I think that meeting went on for an hour, which is an hour lost. It should have just gone straight to development, then argued about the trivial details whilst it is being looked at. They had further calls anyway for updates, so they could have had better updates from the development team.
At that point, I may have been able to tell them:
When it was introduced
What caused this change in behaviour
How serious it is – does it affect other areas that haven’t been reported yet.
So they basically try to discuss things they know nothing about. Ideally, they just need an initial meeting with the “stakeholders” to bring attention to the problem, make sure people are assigned for responsibility/accountability reasons, then arrange a time to reconvene to discuss further.
Stranger Coding Tings 