Practical Implementations of Agile Software Development

So, Agile. It seems like a bit of a buzz word, and my favourite experience of someone completely missing the concept of Agile was someone I interviewed, I won’t name them, but our conversation went something like this;

“Do you have any experience working in Agile?”

“Is there any other way to work?”

Okay, this sounds promising! The blank expression on this candidate’s face when I mentioned things like Scrum, Velocity, and Retrospective showed me that the misconception here was that “Agile” simply meant “working to changing specifications”.

Now, moving into Agile can be a scary and daunting task, and the Agile manifesto is a bit obscure, as are the principles of Agile. So the aim of this article is to give some tiny snippets as to how you can make start to (and you may already be!) adhere to this manifesto and these principles.

My plan, for this article, is to demonstrate the manifesto, and how that should worm its way into your every day working!


Value individuals and interactions over processes and tools

Let’s just let that sink in for a minute. Anybody who has worked with me, especially those who have worked with me at Speed, will agree that I love a flow chart, I love things working like a machine; so this one took a little while to sit properly with me.

The more I think about that “value individuals” the happier it makes me. What this means, is we need to collaborate, understand the skills everyone brings to the table.

This one is arguably the easiest one to achieve, but when you’re mulling over specifications and features, get everybody involved. Start to snowball, get creative. Sit everybody around a table with a whiteboard or some post it notes (Jay Heal loves a good post-it session! Or a workshop as they are more accurately described)

People involved in brand will have different thoughts to offer from those thinking of the product from a marketing perspective, which will be different from the UX gurus, and the frontend ninjas, and the data scientists, and the software engineers.

Magic happens when these people are collaborating, and are each individually valued.

Value working software over comprehensive documentation

Again, this was a culture shock to me. I like my software specifications to be really, really comprehensive. However, drawing up these documents take time, and from a technical delivery standpoint there’s very little value, actually, it’s more valuable from a commercial standpoint.

So, what’s the alternative? User story planning. Rather than drawing up a million specification points, let’s plan the user’s story, and build that.

This pulls really nicely into Test Driven Development, and into YAGNI (You Aren’t Gonna Need It), because you develop and delivery what’s needed.

It is better to deliver small pieces of working software, frequently, than spend months hashing out the too-fine details of a contract and specification.

From a commercial standpoint this sounds counter-productive, but hear me out; if you keep delivering working software, you are going to avoid cash-flow problems where you’re waiting to get the project signed off, and consequently paid for. Additionally, you’re going to continue to gain the confidence of your client, so they’re going to be far, far more inclined to continue to invest into a working relationship, than a black hole of “you’ll get to see it one day” development team.

Practically then, what do we do? Go through the wireframes and the high level conceptual specification, enough to know what you need to develop. Then start coding, as soon as you have enough to work on, start coding something, and make sure you show the client. Prototypes are acceptable, but have something to show and deliver. Don’t wait for an unveil moment, make the client part of your development process.

Side note; you’re also likely to avoid costly test cycles and amendment rounds at the end of a project by working like this.

Value customer collaboration over contract negotiation

This leads on really nicely from the last point. Collaborate with your customer. They know their business, as well as your team know the technology.

Rather than having “no” conversations, have collaborative conversations. Using velocity and backlogs and the point system, once the client has bought into the concept themselves (which you might have to do), they can make decisions about how to spend the resources they’re paying for.

Let the sky be blue, lets the creativity flow.

Practically, liaise with your clients almost constantly. Depending on your environment you probably can’t have them in your scrum every morning, but you can certainly keep them involved. Collaborate with your clients, don’t just negotiate terms.

Value responding to change over following a plan

This is the key thing with Agile, that makes it considerably different from other project management methodologies, like Waterfall.

This is where your sprints, and an accurate velocity, come into their own. If everything is planned and scoped (with points) in your backlog, and you know the velocity of your team, changing direction on a penny shouldn’t be a problem.

Adjust your sprint, and continue collaborating. I’ve been on projects where the entire success of the project has been based on my team’s ability to change direction in an instant, to match a new opportunity, respond to a threat, or based on a new strength or weakness identified.

This is about letting the deliverable lead the project, not the commercials. By working against sprints, you can change direction without necessarily worrying about commercials in the first instance.


Further Reading

Agile Manifesto courtesy of AgileManifesto

Agile Principles courtesy of The Agile Alliance

Featured image credit: Agile Alliance (it is their logo)

Guide for New Developers

Hi guys

I wanted to put in a post here, because I have been working extensively with people who really want to break into web development, from those not yet doing it professionally, to those looking to grow from Junior Developer, and those who I am (in my spare time) mentoring. I find myself giving similar advice quite frequently, so I wanted to summarise here;

It takes time, patience, and passion

I know when I started my career at a trainee, and even before that, I had to put in my own time. What my first job gave me was exposure to a real-life team of developers, who gave me some great advice; some of which I still lean on today.

Your job may entail HTML, or you may be doing spreadsheets as I was, or you may be doing testing; but if you’re surrounded by developers who have lots of real world opportunity to learn. Take advantage of those developers, good developers love sharing their knowledge.

Don’t get distracted by shiny new tech, nail the basics

I read lots of CVs sent to me when I am recruiting for new roles. The worst thing you can possibly do is list lots of awesome new stuff on your CV, when you’ve yet to nail the basics.

The reason for this is quite simple; if (as the ops guy) I can’t trust the quality of your code on basic jobs, you’re never going to get the opportunity to demonstrate your new tech.

If you say you know it, either honestly say you’ve got “some exposure” to it, or a sentiment to that effect, or know it to the level where you’re comfortable demonstrating your knowledge in a competency test.

Learn from reputable sources

Any developer will laugh at this, but if you’re new to the industry you might not know; pay no attention to W3 Schools (or W3Fools as it’s often, less than affectionately, referred)

Depending on what you’re learning Codecademy is a good bet, as are Laracasts and Vue School – if you have someone to whom you look up, who is guiding you on your journey, give them a shout and see if they’ve heard of the site.

On the same token, be wary of Stack Overflow, Reddit, and other community sites. Firstly they can be absolute flamefests, especially for new developers. Secondly, you don’t necessarily know the experience and background those developers had, and even if it sounds impressive, it can be deceptive.

Understand the importance of commercial experience

This sounds really harsh, but I don’t mean it to. You may well have built something amazing in your spare time, but unless it’s reached commercial success and has been run as a commercial development projects; the experience isn’t necessarily that relevant.

Commercial development is far more than writing code. It’s writing it, maintaining it, ensuring it’s stable, robust test processes, client/stakeholder requirements, technical constraints, commercial and time constraints; and so much more.

Don’t be offended if someone discards most of your “spare time” experience.

Everything is a learning opportunity

Failed a technical test? Great! That’s better than passing it when you were sub-par, make notes in the test of what you didn’t get right, make sure you know it next time. Often it will open up a new avenue of knowledge you’ve yet to gain, and that’s a good thing.

Learn raw first

Before you try and learn Vue or React, learn JavaScript. Before you use a plugin, make sure you can code it yourself. Before you learn Laravel, understand PHP and OOP. Otherwise you don’t really know how to achieve the things you’re trying to, you’re just getting someone else to do it. That’s fine, until you can’t use your favourite plugin for some reason, or until it breaks and you don’t understand, at a fundamental level, why.

Finally, don’t give up

Learning tech comes with a cycle “this looks amazing!” – “I nailed it!” – “oh, wait a minute, maybe not…” – “What is wrong with this thing?!” – and if you persevere “this is so much more awesome than I realised!”

So don’t give up on your career or learning tech. Keep going, and know when to ask for help. Nothing worth learning is easy, progress does not come for free, and you’re building a career. So take a breather, get away from your screen.

Caveat: Burnout is bad!

Burnout is a real thing, and is bad. If you’re finding yourself getting stuck and frustrated avoid staring at your screen for hours. Go and do something, anything else. Swim, gym, walk, sleep, listen to music, get away from your screen.

Also, do make sure you leave some time at least every week to do something “just because”. Don’t obsess over the code, it’s not going anywhere, burnout will reduce your cognitive ability, and will make it harder for you to solve the problems you’re having.

Why pessimism is critical to technological success

Hello everyone,

The point I would like to make in this argument is to combat the negative light in which technical leads can appear, when being openly pessimistic. I want to dispel any concepts or perceptions that this is because the person has a negative outlook, wants to block progress, or anything similar; because ultimately that’s not (usually) the case.

Side point: Some “old hat” IT professionals can be negative and resistant to change, usually with years of experience to back it up, sometimes this can be overbearing, this article is specifically related to programming and web development, as opposed to IT infrastructure.

You may not realise it, but you’re pessimistic, too

This isn’t some “glass half full” spiel. When your technical lead is being seemingly resistant to a project or a technology, the likelihood is that they simply cannot promise results. That’s where the pessimism is, however, whether you realise it or not, in some way you share this pessimism, as I am about to demonstrate.

Form Validation (this one is for the techies)

Why do we bother to do any form validation? Because we assume, at some point, the user isn’t going to get it right. Either intentionally/maliciously or accidentally. In this scenario are you assuming your end users are either evil or incompetent?

Testing Cycles

Excluding User Acceptance Testing. Here we are testing for bugs. Does that not mean we’re assuming at least a small piece of oversight or incompetence from our developers? That’s fairly pessimistic too.

Security

It’s not often I’ve come across someone who has deliberately disregarded security. But the nature of considering security concerns by default, means you’re assuming someone out there is going to want to do something malicious to your website/software, right? Fairly pessimistic assumption of the human race (and the bots it creates).

Why your tech lead is being pessimistic

The tech lead has more in depth responsibilities, I’m saying tech lead, but depending on your organisation this might be DevOps or Architecture or Infrastructure. These people must by the very definition of their roles, be pessimistic.

When you sign those contracts, high five the sale, those people go to work. They’re usually committed to an uptime guarantee, a maintenance SLA, and various other contractual obligations. They must be able to deliver (guaranteed) or risk breaching contracts.

A very wise man once said to me “Computers will do exactly as they’re told, no more, no less”, based on that quote (by Jon deVries, if he happens to stumble across this) – we must know precisely what instructions to give the computers/servers in order to make them behave, within a margin of usually 0.1% or 0.01% – else we fall foul of our SLAs.

The considerations, therefore, must cover every eventuality, potentially for a very long time (or the duration of the contract).

So why can’t they just be optimistic?

Well, imagine this scenario

  1. Project manager/salesperson: “Can you make a change to this page?”
  2. Developer: “Sure! Sounds easy, I’ll do it straight on live”
  3. – They hit the wrong button, delete the wrong file, delete and sync the whole directory and kill the whole website, maybe irreversibly –

Optimism = sentences like “It will be alright!”

Sentences like “It will be alright” = complacency

Complacency = downtime

In Summary

Your tech lead, architect, DevOps team, or other technical influencer are not being negative. The pessimism you may experience is an absolutely necessary part of their role, without that pessimism they simply couldn’t possibly be competent at their role.

So be nice to them, they’re likely doing their jobs, rather than being negative, resistant to change, or trying to block sales. They’re humans, dealing with humans, but accountable for the behaviour of computers; which by their nature are not very reasonable.

Layering Software Design

This is a quick-ish article about layering software design, and how to achieve layering in ways which are consistent and useful for the maintainability of your source code. I have seen it done badly I have also seen it done very well, but I thought it was worth covering. Throughout my career I have seen lots of software designs, great. Flow charts and diagrammatic representations of software designs. At this point I think “Great, I can follow this!” – and then I see the code, and the layering is impossible to decipher, and is seemingly only existent in the designer/architect’s head.

Consequently, I thought I would do a quick article on layering your software. I appreciate there are lots of articles around the SOLID principles, and various other related topics, and I urge you to read about spaghetti code and lasagne before reading this article.

This article is aimed at people who have a decent understanding of Object Oriented Programming, but who are in the process of learning about software design and separation of concerns. Alternatively, it may also help those who have large, unorganised code bases to manage, or large projects to design and build.

Quick notice: I’ll keep code samples to a minimum and as concise as possible for the purposes of readability, but said code will be in PHP

The Problem

What we are trying to do, when creating layers of software, is create manageable code, the concerns of which are as separated as possible. Often we are trying to achieve this by defining parts of our application, usually referred to as layers.

Then a professional of some description (software engineer, web developer, systems architect, etc) creates a drawing of the different components to the software and how they should interact with one another. “Excellent!” they exclaim, and off the various developers go to work on their layers. Unless you’re in a strict environment quite often the developers work in isolation, and agree on integration points (or these are predetermined, or predefined).

In my experience, what normally happens at this point is that we have a load of principles designed, and off the team go to carry out the development on the product itself begins. Let’s make the assumption we’re talking about a content management system.

Then the code happens, bug fixes, amendments, changes in specification, and then, eventually… The product is finished! And by this point the design and architecture are forgotten, balls! Nowhere to be seen throughout the codebase.

The Solution

If you’re already in this situation you have a slightly harder job, because you need to understand the intended layering first, and then where you need to get it to. In its simplest form, given these kinds of problems I would be creating layers as they’re required (ones that do not exist) or modifying all code within them, and its usages, to fit into layering practice.

An Example

Let us say that we have a CMS, which currently has a whole bunch of mail() (for non PHP-readers the mail function is documented here), PHP function calls; and we need to enhance the emailing functionality. The specification at the time of creation:

  • CMS must be able to send emails at appropriate times (fulfilled, it does send emails when it needs to)

The new specification:

  • CMS must be able to send emails at appropriate times (fulfilled)
  • We must take new GDPR regulations into account and only send emails to the users which they have approved
  • We must categorise emails at high or medium priority, medium priority messages must not be sent outside of 8pm and 7am, whereas high priority messages must be sent immediately

Likely future specification:

  • In the same instances, we may wish, based on user requirement, to send SMS instead

The way I would look to solve this problem:

  1. Create a Notifications layer through which all systems notifications are sent (end user code sample below), this notification will understand context, so that decisions can be made with regards to type of delivery
  2. Find every instance of mail() in the codebase, and replace it to use my new notifications layer

Userland Code Example

// Create an instance of the notification
$notification = new MessageReceivedNotification($currentUser);

// Set the message which the user has received
$notification->setMessage($theMessage);

// I would normally chain this on, but have not done so for the purposes of readability for those who do not write PHP 
$notification->send();

The Outcome

Now I have a layer in place for all notifications, the next thing to do is make sure that all developers working on the system are aware of this layer, that it is well documented, and everybody knows not to use the mail() function. All notifications now go through the new layer, and injecting new functionality into that section of functionality is a much easier process.

The Prevention

Ideally, you don’t want to end up in that situation in the first place. What you need for this is not only a design of how the layering works, but also a set of rules or standards which ensure that the layering is used in a way which prevents this issue in the first place.

We’ll take the example of a CMS again, with some examples of layers which are required:

  • Notification Service
  • Data Layer
  • Permissions Layer
  • Controllers

And here are some ways that you might introduce that layering, so that functionality can be easily implemented throughout your design.

Interface Facading

Particularly on the Permissions Layer you might want to use the facade design pattern to give a simple interface to interact with the Permissions Layer, this could be further facaded to use helper functions (code samples below). This means that all functionality relying on the facaded layer only ever need to worry about the facade, with no knowledge of how it works, but also that in order to check the permission status you will always use the layer, preventing the problem described above. You may decide that, for the purpose of this shared functionality, you want to make this layer interface through a singleton, particularly if the class itself is doing very little besides providing anaemic functionality to other classes.

class PermissionChecker
{
    public function checkPermission(string $permissionName) : bool
    {
        //  Return true/false based on whether or not this user can carry out this permission
    }
}

function checkPermission(string $permissionName) : bool
{
    $checker = new PermissionChecker();
    return $checker->checkPermission(string $permissionName);
}

Inheritance

Another common way of managing this layering is to ensure that all appropriate functionality extends a base class (inheritance), which encapsulates all the layers shared functionality, again this could facade through to a library of classes. A good example of this would be a Notification Service or Data Layer.

abstract class Model
{
    public static function find($recordId)
    {
        // At this point I am going to fetch a record based on its ID, I can choose to implement caching or other functionality here
    }
}

class Post extends Model
{
    // This class specifically represents the post records, if we're assuming the active record design pattern
}

Data layering is the most obvious to introduce, particularly as most frameworks will have already included this. The important part of the layering process is to understand what else needs to be layered, and consequently how this should occur.

How do I know what I need to layer?

This is impossible to answer really, as you could be programming a blog, or the software behind the next space shuttle launch! The following are not hard and fast rules, but a guideline which you could choose to follow. I personally would consider layering if:

Don’t forget, layers can exist within layers. Your data layer may have layers for caching and database transactions, for example.

  1. When the functionality is reusable (like models)
  2. When the functionality could require modification, which would need to affect everything within its remit (like notifications and adding user preference functionality)
  3. When the functionality is grouped, and might need modification or replacement later (like cart calculations functionality in a commerce system)

How should I invoke my layering?

That very much depends on your use case, personally I tend to consider it like this:

  1. I use inheritance when each instance makes sense to be its own entity (such as a notification, or a record in the model)
  2. I use facading when I am hiding a library of functionality (access permissions works in this case, as you may have a number of functionalities in here, such as super-admin-detection, permissions grid management, IP whitelisting, and infinite possibilities in terms of security management)

Hard Fast Rules (which don’t exist)

Of course, hard fast rules do not exist and every use case has the potential to need to not follow these guides. However, I follow these rules to layer my code properly and ensure it is truly layered/modular.

  1. Do not directly interface with any class which is part of the package/library, that is not the interface or Facade itself
  2. If working within a modular system, never use code which belongs to one module within another (unless it is predefined that this module is dependent on the other)
  3. Particularly within modular systems, having code in separate repositories and IDE projects can help ensure you don’t accidentally use code which is within another module
  4. The moment you think “Gosh, I hope I don’t have to change this later!” you either need to reconsider your base design, or you need to introduce layering there
  5. Follow DRY (don’t repeat yourself) – if you’re copy and pasting code you could almost definitely do with encapsulation, at the very least, but potentially your code should be in its own layer with an interface to allow your modification

Summarised Points to Take Away

  1. If you draw a design, and you have a layer, ensure some kind of physical representation (base class, interface, facade, etc) of that layer exists
  2. Ensure if you’re using layers they’re well documented, and everybody knows they need to use your layer, and how
  3. Layers are important for injecting new functionality later, and preventing the duplication of code

Thank you for reading!

6 tools I couldn’t live without

Hi everyone

So today I thought I would do a quick post, as it has now been just over a year since I started as the Senior Systems Architect at Speed Agency. We’ve had an amazing year, seeing the design, development, and delivery of a number of bespoke systems, including our own modular content management system. Of course, to achieve all this we use a whole bunch of tools. Here I thought I would summarise my favourite;

#1 Digital Ocean

Now, I know there are competitors out there, however I haven’t used them. The reasons I love Digital Ocean can be summarised here:

  • We run a very strict set of processes with regards to the deployment of changes to our live environment. The snapshot functionality means I can have a single (or multiple) staging environments built in next to no time
  • Their customer service is absolutely top
  • Their availability is high, and their prices very reasonable
  • The server monitoring is really pretty damn good, especially as it’s essentially a free extra
  • And all the usual stuff to do with Volumes, Floating IPs, etc.

More information about Digital Ocean

#2 Status Cake

I’ve used a number of different suites to monitor uptime, I’ve never found one which is better for configuration, server and website monitoring (amongst other things). Also, very very few false negatives – which are a nightmare to manage if you’re handling SLAs on uptime!

Track your uptime and server statuses with Status Cake

#3 Packagist

I’ve done a blog article on Packagist before, however I have to say I love it. The power of managing modular code and dependencies through Composer, added with the closed-source nature of private packagist is just great.

Find out about Packagist

#4 GitLab

We started using GitLab for managing issues and our Git repositories. I’ve got to say, whilst it might start to fall down against its Goliath-size counterparts (such as Atalassian’s BitBucket + Jira haymaker of a combo), it has lasted us very well, it’s a great system to have, it’s open source, easy to use (particularly if you’re familiar with GitHub) and has been a great toe-in-the-water for this style of project management.

Learn more about GitLab

#5 Confluence

I’m a true nerd for documentation. I love it. I mean I love it more than I love flow charts, which is really saying something. Confluence is phenomenal. For managing, exporting, modifying, discussing, sharing, and structuring your documentation this is the absolute bee’s knees. Seriously, if you need to document your source code, project paperwork, or anything in the software development arena, sign up for it, right now, don’t even hesitate.

I don’t know why you don’t already have Confluence

#6 draw.io

There is a standing joke in my office, in which I am referred to as Sheldon (though my computational personality tends to find me also referred to as Laurie Bream) – this is because of my absolute adoration for flow charts. From processes to systems designs to user-workflows I absolutely swear my draw.io, which allows you to draw these diagrams, export them as XML files for later, and export as a number of useful formats (PDF, for example).

Get your workflow on with draw.io

In Summary

Tools and software should make your life easier. The above 6 things have made my life infinitely easier, and helped me structure, grow, and enhance my team’s capacity and capability by providing smoother, more efficient processes and workflows. I can’t take all the credit, of course, all those tools were at some point referred to me by a colleague, friend, Search Engine, or somewhere; and none of them would have any effect if my team didn’t take the whole hearted approach to adopting the things that I have mentioned above. Every team has a critical mass which makes systems effective, and my team are the best at adapting to our ever changing requirements.

I’d love to hear what tools you have which make your job easier, I can’t promise I won’t think “oh, that’s a good idea!” and consequently adopt the tool myself 🙂

Until next time,
Johno

Edit: Considering this is essentially 6 links I thought I’d best state – there’s no commercial interest in this post, I’m in no way endorsed by those companies, have no affiliation, no referrer links or anything included!