Month: October 2016

Why you MUST run your Unit Tests as part of your Build Process

~ Adam ~ Leave a comment

I was browsing StackOverflow the other day (as many geeks are known to do from time to time) and read an answer which describes writing Unit Tests as being like going to the gym. Now, I’m not sure about the final few sentences about finding another job but I do really like the analogy. It’s hard when you start out but the more you do the easier it gets and the more value it adds.

Now, like going to the gym there are couple of fundamentals which if forgotten can undermine everything. Unit Tests don’t require proper warmups or cool downs but they absolutely, definitely, must be run on the build server for their real value to be exploited.

Let me explain why.

Developers are often hackers by nature, we install different things and experiment. That’s what makes us good at our job, it’s also what makes every developer’s computer slightly different so software which runs on one machine could behave very differently on another.

What’s worse, if your developer is in a rush or having a bad day they may completely ‘forget’ to execute the tests before committing code. Now, instead of vigorously tested and proven code being added to source control you’ve got a risk.

Tools like NCrunch help reduce this but the only absolutely foolproof way to ensure that all your tests are executed and passed before deployment is to get your server to run them. Missing out this vital link means you’re opening your build and deployment process up to human error, something you should be very nervous of doing.

Almost all build servers have the capability of running tests so dig out the manual and make sure that when the tests fail, the build fails!

Setting SMART Goals for your Team

~ Adam ~ Leave a comment

Annual reviews are often one of those things we do as a box ticking excercise. It’s dull, time consuming and there are often more interesting geeky projects you’d rather be working on.

Words like SMART buzz around our brains for a few weeks and then are promptly forgotten (much like the goals) until the same time the following year when each goal is ticket off as “Done” or “No Longer Relevant”.

Surely there’s a better way?

Let’s look at what SMART stands for…

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Time Constrained

Your business may have different words but the jist is the same.

I want you to think about these words differently. Instead of writing goals for someone to achieve I want to think about User Stories. It’s reasonable to demand that any PO writing new features for the backlog should create them so they are Specific, have good Acceptance Criteria, be feasible to implement, be a valuable addition to the software, and should fit into a single Sprint.

In other words SMART is just another way of setting detailed and unambiguous instructions!

So now we know that SMART is simply a way of writing clearly let’s look at what goals you should set.

What do you expect your Team Member to be doing for the upcoming year?

This may sound like an obvious question but in my opinion annual goals shouldn’t all be about Continuous Personal Development or an arbitrary “I’d like to lean that” because these are the first things which will be abandoned when you have a tough day. Instead look at what your department goals are and propagate these through to your team.

If you have a major release coming up then set that as one of the goals. If you need to analyse system performance or memory usage then write it down. What you will find is instead of irrelevant targets which will be abandoned in favour of more pressing work your team will suddenly become accountable for getting the releases out to customers. Not only that, but they will see that their day to day tasks are being used to measure performance instead of the “Nice to Haves” which were abandoned as soon as the year hit a rough patch.

You will quickly find that most developers will much rather have a goal of “Create Offline Sync Mechanism as specified in Feature 123 before the end of January” than something vague like “Improve the Support mechanism”. For one thing there’s a lost less ambiguity as to whether it’s actually been achieved! Remember, less ambiguity means fewer awkward conversations when you come to assess goals, that has to be a good thing!

In conclusion, setting clear (or SMART) goals for your team which actually reflect the work they’re going to be doing day to day is a great way of getting investment in your department’s objectives and helping making those annual review forms much more relevant. Learning goals are good, but they shouldn’t be the core of a Team Member’s assessment.

Restructuring your Sprint to Produce Finished Software

~ Adam ~ 3 Comments

If your company is anything like many of the teams I’ve worked with your Sprints are a planning tool used to break down monolithic projects into smaller pieces to track progress.

In the real world big releases often pressure development teams to adopt more established project management techniques to hit deadlines. A PM will nominate a certain number of weeks for development (hopefully based on estimates your developers have provided) and then subsequent time for testing, bug fixing and UAT. The Development Manager will then allocate time into those Sprints.

But wait a minute? Doesn’t Scrum team us that we should be able to produce full working software at the end of each Sprint? If that’s the case then why are we saving all of our testing and bug fixing until the end!? It feels to me as though we’re running Sprints but ignoring the line of the Scrum book which talks about finishing a Sprint with deliverable software.

In Rolling Rocks Downhill Clarke Ching calls this GETS Software (Good Enough To Ship), it’s a term I like. In his book the team would build feature after feature however at the end of each iteration they ensured the product was GETS. That meant that if something took longer than expected or their budget was cut the team would always be able to fall back on the last version.

In a typical PM managed project I envisage features a development phase, when new bugs are carefully and painstakingly introduced. Then a testing and bug fixing phase, where they are removed.

waterfall_bug_flow

If however you commit less work to your Sprint, let’s say half the amount then your developer can spend the second week refining their work, working alongside the QA, designing upcoming features, and removing any bugs which are found.

This will obviously reduce your Sprint Velocity, however it will mean that whatever work is completed is completed, reasonably and as Clarke puts it GETS. However without the need for long and laborious bug fixing phases this time can often be reclaimed.

agile_bug_fixing

This approach is game changing for a number of reasons. Firstly your quality isn’t compromised, instead of a quality decline and then improvement your software stays at production quality. Second, should your customer, Product Owner, or business priorities change you can update your plans (maybe even delivering early). Surely that’s what we mean by Agile!?

Many thanks to FooPlot for the brilliant site I used to create these graphs and Jing for the screenshotting and labeling software.

The Phoenix Project Book Review

~ Adam ~ 12 Comments

I recently read The Phoenix Project, the definitive and often referenced DevOps Business Novel by Gene Kim, Kevin Behr, and George Spafford.

I have to admit I’ve been putting off reading this book, perhaps I had some misgivings about replacing Scrum techniques with the new craze of DevOps. Having decided that I was going to invest my time I was tested once again when I realised that Bill, the book’s main protagonist is an infrastructure guy… I’m a Development Manager, I want to know what DevOps can do for do for me not what I can do for the other guys!

That however was the last time I paused before devouring the remaining 370 pages.

Bill’s first few days after his promotion are littered with disasters. He has a project to deliver, infrastructure problems to resolve, and political ambushes to endure. In other words, he’s in the situation we’ve all experienced when teams aren’t communicating and colleagues are so stacked up with their own projects and priorities that they simply can’t assist each other.

With the timely arrival of Eric, the new potential board member Bill slowly equips himself with the tools he needs to resolve his infrastructure headaches and get the Phoenix Project back on track. Eric, acting as a kind of DevOps Yoda helps Bill gain an understanding of the four different types of work, the Theory of Constraints, Systems Thinking and see the value of Automated Deployments.

There’s a nice appendix at the end which helps consolidate the ideas and explains some of the ideas away from the story. There are also some mind blowing statistics about how some of the big web companies such as Amazon, Google, and Netflix.

So would I recommend this book to others? Absolutely! In fact I have, repeatedly to friends and colleagues! Whether you’re a developer, infrastructure guru or IT manager this book will introduce you to several new ways of thinking about workload management and IT processes.

Playing with Microsoft Cognitive Services

~ Adam ~ Leave a comment

It’s time for a little fun – inspired by Martin Kearn‘s talk at DDDNorth I fired up the Microsoft Cognitive Services Website, signed up and got myself a key for the emotion API. It didn’t take me long to get up and running!

I tried briefly using the SDK library but found some trouble with strongly typed names, deciding the abandon that approach I used the method Martin recommends on his blog and simply downloaded the json myself and parsed it.

Here’s my code:

        var _apiUrl = @"https://api.projectoxford.ai/emotion/v1.0/recognize";

        using (var httpClient = new HttpClient())
        {
          httpClient.DefaultRequestHeaders.Add("Ocp-Apim-Subscription-Key", _apiKey);
          httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/octet-stream"));

          //setup data object
          HttpContent content = new StreamContent(new MemoryStream(File.ReadAllBytes(filename)));
          content.Headers.ContentType = new MediaTypeWithQualityHeaderValue("application/octet-stream");

          //make request
          var response = await httpClient.PostAsync(_apiUrl, content);

          //read response and write to view
          var responseContent = response.Content.ReadAsStringAsync().Result;
          var objResponse = JsonConvert.DeserializeObject<RootObject[]>(responseContent);

          var image = Image.FromFile(filename);
          using (var gfx = Graphics.FromImage(image))
          {
            foreach (var face in objResponse)
            {
              gfx.DrawRectangle(new Pen(Color.Red, 5),
                new Rectangle(new Point(face.faceRectangle.left, face.faceRectangle.top),
                  new Size(face.faceRectangle.width, face.faceRectangle.height)));

              var text = this.GetText(face.scores);

              gfx.DrawString(text, new Font(FontFamily.GenericSerif, 64), new SolidBrush(Color.Red),
                face.faceRectangle.left + 24,
                face.faceRectangle.height + face.faceRectangle.top);
            }
          }
          this.pictureBox1.Image = image;
        }

I’m very impressed with how easy it is (in fact most of it’s being used to update the picture box in my little Winforms app!).

What do you think? Do I look about 65% surprised?

emotion_screenshot

DDDNorth 2016

~ Adam ~ 3 Comments

I was very excited when I saw the announcement of DDDNorth earlier this year. I’ve attended the conference several times before and to see it was once again in Leeds really gave me no excuse not to attend!

Despite having a rather late night the previous evening I was one of the first there, in fact I think I accidentally tailgated a speaker inside and sat quietly in the corner until the masses arrived.

For those of you who don’t know the DDD events are free, one day conferences focused at .NET developers. They’re held around the country and have a very high standard of speakers. DDDNorth is our annual event and usually circulates between the Universities of Leeds, Sunderland and Bradford.

The first session I attended was “Machine Learning for Muggles” by Martin Kearn and it was one of the best geeky talks I have ever attended.

Martin demonstrated how to use the Azure Machine Learning API to upload your own data for analysis. He then took a photo of the audience and used facial recognition and text analysis to ask questions like “show me the happiest person”. Before today I’d always assumed machine learning was only for the likes of Google, before the first coffee break I was already wondering whether I could use the APIs in our own products.

The second session I attended was “10 More Things You Need to do to Succeed as a Tech Lead” by Joel Hammond-Turner. I’d attended one of his talks before (entitled 10 Things You Need to do to Succeed as a Tech Lead) and with my recent change in role I felt it was a wise choice session.

I was right. Joel gave us a good list. It contained tips on requirements, instrumentation, and team training. I was particularly impressed by his thoughts on managing and measuring technical debt!

The last session of the morning was “You read The Phoenix Project and you loved it! Now What?” by Matteo Emili. Having recently bought and demolished TPP while on holiday this was the session I was perhaps most excited about. Matteo argued for pragmatism, he told us that in order to sell process changes the value must be determined. He quoted the common phrase “you can’t manage what you can’t measure” and discussed in depth how you should use the Build-Measure-Learn. There were even a few tips and ticks towards the end to help us get our automation deployments going!

It was lunchtime, which meant sandwiches and GROC talks (I have always been curious to know what that stands for).

I arrived in time to see a few interesting mini-talks. The first was on using the C# interactive window in Visual Studio, the second was around ARM templates for Azure, and the final one was entitled “What’s the Point of Microsoft?” and was a tongue in cheek presentation about how the big tech players compete in today’s software and hardware world.

I’d love to continue, I’d love to tell you about the Microsoft BOT API talks I had lined up for the afternoon. Alas it was not to be, it was around this time that the office called to tell me that several hundred members were having issues with their accounts. No rest for the wicked!

I’d like to take the time to thank the DDDNorth team for putting together yet another fantastic event. The speakers this year were superb and if I get the chance I fully intend to catch the sessions I missed elsewhere in the country at a later date. See you next year!