Tag: process

The Presentation – how it went

The other day, I mentioned that I was preparing for a presentation.

The aim was to – as a minimum – get people to follow the existing process. The ultimate aim was to try and get buy-in for following a full out Test Driven Development methodology (TDD).

My previous post about this generated some awesome advice – some mentioned that I should pin point a case study of where a process wasn’t followed. A former manager suggested I avoid death by power-point, and instead cover a live example of how TDD can speed up the development process. Others suggested that I follow a four point rule.

It’s just sods law that I woke up in the morning with a cracking headache and feeling sick. Awesome. I dragged myself into work, regardless – I’d put far too much thought and effort into this to call in sick on the day.

I think I managed to incorporate elements of all the advice I received. I opened up with a brief section on ‘when things go very, very wrong’, to establish that I’d already had a trial by fire for this kind of thing. I then demonstrated how time can be saved and pit falls avoided using TDD. I closed off with my suggestions that we adopt a TDD-like methodology, or at the very least follow the process we already have across the board, with no excuses. All issues were condensed down to a maximum of 4 points each, to avoid information overload. I then opened up the room for discussion.

Unfortunately, the management were unable to attend the meeting, which meant that I was really working from the ground up. It turns out that the most powerful tool in my arsenal was the fact that the product recall notice (the price of not doing this right) is still on the internet. The twitter posts are still there as well. It’s hard to argue against that.

Overall – I don’t have full buy-in of TDD yet. However, there is an agreement that the process as it currently exists will be followed more stringently. The value of unit testing was accepted as common sense, but the same old arguments reared their heads – resources and time. It was agreed that we would need more drive from a management level to get resources dedicated to setting up a proper nightly build system, and that is still the main issue with what I’m trying to get in place.

After the presentation, my manager asked me to send him and the other managers a summary of the results of the presentation, which has given me the opportunity to not only give feedback, but to also push for giving the presentation to the management.

So, the battle isn’t over yet. I haven’t been shouted down, meaning I have plenty of room to keep the argument for this going. I feel I have managed to move things forward a small step, which as the new girl in the office, I don’t think is bad going. There is still a long way to go, and I’ll no doubt be blogging about it as I continue pushing for it.

I’d like to once more give a huge thanks to all the people who gave up their time to give me advice on how to proceed with this presentation – it’s very much appreciated, and I don’t think I would have gotten a team to agree to follow the process more closely without following your advice! You’re all awesome!

The Zone

The Zone is something that most programmers will know about. It’s that place of quiet in our head that allows us to focus all of our attention on one problem, to the exclusion of everything else. My Dad calls it ‘hyper focus’, which is also quite apt and probably more accurate.

I’m personally of two minds whether the ‘Zone’ is a good place to be or not. I can never determine how I go into it – all I know is that if I find something interesting enough, the rest of the world falls away. All that is left is my ‘item of interest’. People have been known to shout or throw things at me to get my attention when I’m in this place. A ceiling once fell in behind me while playing Sonic the Hedgehog when younger, and I never even noticed.

I’m not sure if the quality of my code gets any better while I’m in this place. Some claim that their code is the better for it. What I do know is that coming out of it, either due to someone else forcibly distracting me, or coming out of it naturally, is horrible. It feels like waking up after only 2 hours of sleep. Confusion reigns as I try to catch up on everything that may have happened while I was in the Zone. People have to repeat themselves a few times before I get what they were saying. It’s like emerging from a dark fog into a brightly lit room – you’re temporarily overloaded by all the things that you had not been noticing whilst in your own world of productivity. And then the overwhelming urge to go to the toilet, or eat/drink something. If I’ve ever gotten stuck in the Zone, I’ll often find I have been there for hours.

Some people have different methods to get into the Zone. Some need absolute quiet. Some need music. Personally, I find I just … get there. I habitually wear ear phones and listen to upbeat music whilst at work, but that’s mainly to drown out the noises of people around me so that I can concentrate when I’m not in the Zone. When I’m in the Zone, I don’t even hear the music. Or anything. Which is one of the reasons I find it kind of a scary place to be. I’ll end up in the zone through reading a book, playing a computer game, or doing work.

I actually try to avoid getting there these days. Which is actually easier said than done, given how easily I slip away to that place. I keep my usual Spotify playlist random (feel free to check it out here. Don’t judge me!). I try to make a conscious effort to take breaks every hour or so.

So, is the Zone a good or bad place to be? Honestly, my verdict is leaning more towards ‘bad’, given how awful I feel after coming out of it.

On the Job Training as Knowledge Gathering

This week, I am being trained on an application which I am to build the next version of. Initially, I thought it would be a bit of a waste of time. I’ll be writing the all new singing and dancing version on a completely different platform, so who cares about being trained in the old one?

Well, it turns out I should. Being in a training room with other people who are also learning it is providing me with invaluable information. So what if I know how the app is working under the hood after reading the code base for the last couple of weeks? I have pages of notes on things that need to change that may have made it into the next version without this kind of feedback. I am watching how users – new and old – are using the application in its current form. I’m experiencing some of the strange niggles first hand.

This post isn’t to down talk the application as it exists now – like anything these days, it has its great points to. What this is about is being aware that just watching your end users – be they trainers or newbies – use your application is like a gold mine of information on what could be better, what actually works, what they want to see more of, and what they want to see less of. They don’t care about what’s under the hood. They just want to make their working day more efficient.

Although it’s bound to be time consuming, I can’t help but think that having user groups together to play with an app well before release in an observable environment will do that app more good than any number of revisions to a product specification. I’m not talking beta testing here, as what I’m experiencing now is active feedback on an application where the new ideas are still being collated. It’s something I’m going to be trying to push for going forwards in my own processes. It’s not a new idea. I’ve just never thought of applying the idea to a training scenario before. An established application in a training environment is certainly a great candidate for this treatment.

Going by the information that I have noted down after just two days, observing a hands on training session group is providing more value to me as a software and UI developer than any mass emailed questionnaire ever could.