stuartdobson.net

Story Points are Utter Nonsense

2023-05-23T03:53:00.007+00:00

For over a decade, I've lived a lie.

I made myself believe that Agile Story points made sense.

I rationalised it like we all did.

"They map to complexity, not time".

Yet we spend hours on Sprint Planning meetings deciding how many jobs we can fit into a Sprint - a unit of time. Also - doesn't complexity relate to time?

"They're a rough guide, they're not supposed to be accurate."

How on Earth did we end up with a unit of measure that is "not supposed to be accurate"?

"It depends on experience of the person doing the job."

This is like saying the length of a centimeter depends on the tape measure you're using.

"They're a measure of relative complexity."

Relative to what? Another story you did which didn't have an accurate estimate?

"We use shirt sizes/Fibonacci/animals/fruit."

Is this supposed to make it easier to understand? Why can't I give a task 4 points?

"We have to agree on size before we can move on."

Yes, let's ensure the contractor watering the plants gets a say on this.

"Planning poker helps us find a consensus."

I guess it does, once everyone is worn down enough to just agree.

A recent discussion highlighted the absurdity. I asked people to define what story points were, and just like the multiple meetings I've had over many years, it was clear that nobody could agree.

I got the usual selection of contradictions and confusion.

Story points have no unit of value
Story points are a non standard unit of value(?)
They're team specific, so they don't map to anything
They don't map to time, but they do map to a sprint, which is time
They map to complexity, but how much depends on the experience of who is doing the job, and the maturity of the team, which changes over time.
They're only supposed to be used for Epics, and Stories are estimated in time
A Story point is like a chicken

Yes, that was a legitimate answer from someone attempting to explain what a story point was.

It's like a chicken.

This is a real thing a human said:

"I once had a Scrum consultant working with our team who said a story point can be a chicken if you wanted. Find a story that the team can say is a very simple piece of work and call that your chicken. This chicken is then 1 story point. A story that would be twice as difficult or complex would be a two-chicken story (or 2 story points). It's over-simplified, but perhaps you get the point."

Erm, sorry, but I don't think I do...

Agile is a cult. This is evident in the explanations which pervade this space that are often repeated ad nauseam. One of these explanations becomes our rationalistion: "It's Agile. It's flexible - you can do it how you want."

It's time we admit that it doesn't work and it's really just a cocktail of nonsense, designed to put a framework around what is, in the end, an impossibly hard thing to plan.

I'm going to invent a new system of organising workloads. You have planning meetings once every 13 days unless there's a full moon. In those meetings you can play Snakes and Ladders to determine the "relative complexity" of a ticket. Then you throw that number out, and just do the job anyway. Every 15 minutes someone has to stand up and shout "Bingo". Then someone else picks up the ball.

Actually, this makes as much sense as our Agile rituals, so it'll probably take off.

I apologise to the workers of 2040.

6 Ways ChatGPT Can Help You Code

2023-01-07T23:05:00.003+00:00

ChatGPT is blowing up at the moment, and for good reason. Its capabilities are unlike anything we've ever seen.

Will it take our jobs as developers? No. But, if used correctly, it will transform them completely. Here's how I am already using ChatGPT to turbocharge my productivity. It's fair to say if you're not using this, you're going to be at a significant disadvantage.

Here's just a few ways you can use ChatGPT to rocket boost your development work.

Provide a starting point

If you know what your code needs to do, ChatGPT can quickly fill out the functionality for you:

Understanding code

A simple example but a great way to get some context on badly named or hard to follow functions.It’s also very good at explaining the different decision paths and giving useful examples.

Improving Code

Add more functionality to your code based on your suggestions:

Give some more suggestions for improvements:

Simplifying code, with explanations

I originally wrote this method (a looong time ago), and wanted to see how ChatGPT could make it simpler.

public static void ConvertImageToThumbnailJPG(Stream input, Stream output, int thumbnailsize = 200)
        {
            int width;
            int height;
            var originalImage = new Bitmap(input);

            if (originalImage.Width > originalImage.Height)
            {
                width = thumbnailsize;
                height = thumbnailsize * originalImage.Height / originalImage.Width;
            }
            else
            {
                height = thumbnailsize;
                width = thumbnailsize * originalImage.Width / originalImage.Height;
            }

            Bitmap thumbnailImage = null;
            try
            {
                thumbnailImage = new Bitmap(width, height);

                using (Graphics graphics = Graphics.FromImage(thumbnailImage))
                {
                    graphics.InterpolationMode = InterpolationMode.HighQualityBicubic;
                    graphics.SmoothingMode = SmoothingMode.AntiAlias;
                    graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;
                    graphics.DrawImage(originalImage, 0, 0, width, height);
                }

                thumbnailImage.Save(output, ImageFormat.Jpeg);
            }
            finally
            {
                if (thumbnailImage != null)
                {
                    thumbnailImage.Dispose();
                }
            }
        }

Documenting Code

ChatGPT can easily add comments based on what the code is doing.

Writing Tests

And now, for the biggest time saving operation - automatically defining test cases, AND writing those tests:

It continued to give me all the tests I needed. This alone saved me a couple of hours.

Be careful relying on ChatGPT

You’ll notice some issues in the generated code - test cases 3 and 5 for example have inputs and assumptions which are not quite right. However, it’s trivial to change this in the real code. The important thing is that you are aware that ChatGPT often makes mistakes and you must check its work.

It can also be a little stupid at times:

A great companion

ChatGPT is not going to do all your work for you. But it can be an excellent partner - helping with a lot of grunt work and providing comprehensive suggestions. It’s up to you to vet those suggestions.

For simple code, this can be a massive time saver. For more complex code, be careful that it doesn’t give you more work by providing complex solutions which don’t quite work. It’s best to break the code down as much as possible as it seems to cope much better, most of the time.

Productivity 100x

Don’t think of ChatGPT as a threat to your job as a developer. Think of it as a critical tool, which can help you increase your productivity by several orders of magnitude..

Anyone not using it will find themselves left behind.

Start learning how to get the most out of ChatGPT today.

Why chasing Unit Test coverage can be a bad idea

2022-11-13T23:00:00.008+00:00

In the long running battle between management chasing metrics and developers just trying to get the job done, (hi boss!) I wanted to provide some less obvious examples of why chasing code coverage is a damaging process.

Why Unit Test Code Coverage targets are bad

Code Coverage can be gamed, incentivising low quality tests

If the coverage percentage is all that matters, there are many ways to increase that number without actually improving the quality and reliability of the code. Having a test doesn’t mean no bugs - it just means the code is being run by a test, that the pathways through the code are exercised by another piece of code.

There’s not really any link in these tests to importance of functionality, or even any consideration of code doing the right thing, just that it’s being exercised.

Tests add a maintenance burden

In the writing of low value tests written only to satisfy KPIs, developers are actually making more work for themselves in the future.

All code adds a maintenance burden. Tests are code so adding tests adds to this burden. If they’re not valuable, they’re detrimental.

Chasing coverage leads to more brittle tests

The more coverage you have, the more brittle your tests actually become. By covering every internal path of a method, you are tightly coupling the tests with the implementation details.

This goes against the spirit of testing. You should be testing the functionality of the code - the inputs, outputs, and decisions it makes, and the edge cases.You don’t need to be too concerned with how it makes those decisions.

This in turn makes you write tests the right way - thinking about the desired functionality instead of the coverage.

Give a false impression of robust code

It should be obvious but it’s often overlooked. High coverage, which as discussed leads to low quality tests which often don’t test the right things, gives a false sense of security. You may have 80% coverage but if the last 20% is all the business critical functionality, or vital areas of the code, this could be hiding big problems.

Chasing metrics hides opportunities to improve the code quality

Let’s remember why we write tests in the first place. It’s to have confidence that our code is meeting the requirements, can handle edge cases, and is free of bugs. By focusing on coverage, you are missing the opportunity to write tests which do this - tests which actually lead to better quality code.

Thinking about what scenarios you need to cover when writing code, encourages you to write the code in a testable way. If you write it in a testable way, you’ll be more likely to write tests - valuable tests. Better still, you’ll be more inclined to write the tests, or at least stubs of them, first (Test Driven Development).

If you write code and then add tests as an afterthought, you’ll probably focus on coverage instead of functionality, because you’ll be thinking about “adding tests” and increasing coverage - rather than thinking about the original intentions of the code.

Why Code Coverage is good

Despite all these issues, Code coverage has a place in software development and there are some benefits to monitoring it, as opposed to incentivising it.

Identifies areas of low coverage

In combination with your knowledge of where important functionality lies, you can see where tests are needed. Without code coverage metrics, it’s pretty hard to do this.

Instills a culture of continually adding tests as you go

Let’s not forget that we want to be writing tests. We’ll get good coverage just by doing it as a habit, and by monitoring the coverage, we’ll see it go down if we write code that’s untested. So this encourages us to keep up with writing tests as we add features, and helps us see when we’re not adding them.

This keeps test writing on everyone’s minds, and influences the culture to make people value tests.

If you’re not measuring, you don’t know if you’re improving!

Conclusion

This article is very much a developer’s perspective, but at the end of the day, code coverage is a Return on Investment decision. Care should be taken on where the coverage is increased. Writing tests for existing code should be done in a way that prioritises high value, low effort new tests.

Code coverage is a good thing in that it gives a picture of where you are, and helps you monitor your testing journey. It’s always problematic to incentivise metrics, or even push to maintain a level. But we should be mindful of the level of coverage.

Focus on code coverage detracts from why you should be writing tests in the first place. The important thing is that we build tests around requirements and edge cases - tests which exercise and document real life scenarios. Tests are not about lines of code covered. This is an indicator - not an incentive.

Writing tests is a very important part of software development. Do it for the right reasons, and it will be done well.

Microsoft Certified: Azure Fundamentals

2022-09-12T11:34:00.006+00:00

Another month, another Fundamentals exam 😄

I got this one because it was free after doing some online training through Microsoft. But - it was about time I got it.

I've been using Azure since it came out but never got certified because there's a lot of Infrastructure stuff in the exams which don't particularly interest me as a developer. In saying that, I found the exam material high level enough to be interesting and I managed to fill in a few gaps.

Most notably - I enjoyed playing with the Azure Infrastructure map. It's a cool visualisation tool that lets you explore all the Azure infrastructure, all the datacentres, undersea cables, even satellites. You can take a virtual tour of a datacentre and learn about Azure in space! Cool stuff.

Foundations of Humane Technology - Course completed

2022-07-10T11:54:00.005+00:00

Back in January (has it been that long!) I completed the Foundations of Humane Technology course from the Center of Humane Technology. You may have heard of them, they made the Netflix Documentary "The Social Dilemma".

If you haven't watched the movie, it's well worth a watch, delving into the often devastating impacts of Social Media.

The course explored how to build technology in a more responsible way to minimise the harmful consequences of the technology you build. It's perfect for technology oriented Product owners and developers like myself, requiring us to think about externalities and unintended consequences, and aligning our values with the products we build.

I was made to reflect on how technology has impacted me personally, and realised how my health, cognition and attention were impacted by technology overuse.

I was obliged to acknowledge that I am very privileged and lucky, I don’t have any major accessibility issues and my demographic allows me to avoid most prejudices. This led to reflecting on the injustices and oversights suffered by many and encouraged me to think about how I could improve my products to address these issues.

One section, Creating Shared Understanding, was particularly interesting in highlighting the role technology has had, especially recently, in dividing society. But this section gave the opportunity to think about how we can improve this situation moving forward.

For me the most compelling aspect of the course was the section on Minimising Harmful Consequences. Learning a lot about the consequences of various social media platforms, it was easy to conceptualise the problems that this course is trying to address. These consequences are numerous and are having significant long term impacts on society. I’d like to explore these topics in much more depth.

The course concluded with “Helping People Thrive”. Not content with just reducing harm and injustice, we were pushed to consider how we would actually improve people’s lives with the technology we build. And not just improve their lives by giving them better content to look at - of course - but to truly improve people’s happiness, wellbeing, and community.

By the end of the course I had clear goals for moving forward.

As a software developer working with AI platforms I want to build awareness around these systems, showing people how they work and what they are doing. AI is often (rightfully) criticised for its controversial applications. I want to continue highlighting the dangers while also alleviating concerns where they are unfounded. In the products I develop I want it to be clear what is happening with users' data, which parts of it are being subjected to AI analysis, why, and how.

I’m also keen to teach other developers and product owners about the harms of certain user interfaces (e.g. autoplay) and advocate for better security and privacy in all technology.

If you work in technology, I highly recommend this course. It’s free and took me about 15 hours.

Microsoft Certified: Azure AI Fundamentals

2022-03-28T10:40:00.011+00:00

Woo!

This was by far one of the most fun exams I've had to do.

I've learnt a really good overview of Microsoft's AI services. I learnt about Image recognition, Bot framework, Speech recognition, Language processing, Knowledge mining, and more.

I've worked a little with Microsoft's Cognitive Framework in the past. In 2016 my team won our company's Innovation Day prize for building an app which monitored employee happiness. We made it into a joke - Big Brother spying on you all day to determine your emotional state at work by taking a photo of you every few seconds and analysing your emotion. It was a joke, man.

Fast forward 5 years and there are companies out there doing this as a business now. How effective it is I'm not sure. Given that I ran Hide the pain Harold through the Emotion Service and he got 99% happiness, I have my doubts.

Anyway, there is so much cool stuff you can do with the Azure AI tools. I recommend giving this exam overview a good look.

Unit Tests - Keeping them clean and simple

2021-10-04T05:27:00.027+00:00

Tests should be split up by behaviour

One behaviour, one test. This means don't test more than one thing in a test. Ideally there should be Acceptance Criteria clarifying each expected behaviour. This gives you a solid starting point, but Unit tests can expand on these scenarios by covering edge cases.

Telltale signs of breaking this guideline include:

Multiple "Act" steps (this is a big sign)
Multiple asserts throughout a test
Multiple unrelated asserts at the end of a test
Data is being changed after the Act step
Using the word "correct" in your test name - indicates vague expectations

Don't be afraid to create lots of test methods for a single scenario or unit under test, testing various behaviours. When writing unit tests, you can make a new class for each scenario, this gives you power over the TestInitialize/Cleanup methods, allowing you to keep your tests cleaner.

Readability is Everything

The number one thing to remember when writing tests is that they need to be clear. This means they should be simple and concise, and separated by requirement.

Place the same importance on readability as you would for production code. We spend 10 times more time reading code than writing it. It needs to be extremely easy to read in order to be maintainable.

By making the tests readable, you should immediately be able to see what your tests are doing, and easily see how the tests in a class differ from each other. So bear this in mind, especially in tests that require large amounts of data setup.

Think about what the test does and ensure this is communicated clearly. You can do this in several ways:

Name of the Test

The industry standard format for naming tests is:

UnitUnderTest_Scenario_Expectation

for example:

MyMethod_WhenNoResults_ReturnsException

The reason for this is so that we can see at a glance what is being tested. We should be able to quickly discern what the test is testing, what the scenario is, and the expectation.

Using the word "Correct" in the expectation part is not ideal, because it does not make it clear what "correct" means. Be specific about what your test expects.

Test Description Tag

A clear name for the test is paramount, but if not enough information can be conveyed in the name, consider use of some kind of [Description] attribute or other labeling on the test to provide more information.

Comments

Throughout your test, consider the use of comments to make it clear why you are setting up data in that way, to highlight when you are performing the action, or anything else that may not be immediately clear.

Arrangement

Consider the format of a test:

Arrange: This is where you set up the data/objects that are required to perform the action.
Act: This is generally one line, where you call the method / unit under test, or perform the required action.
Assert: This is where you check that the expectation has been fulfilled.

You don't necessarily need to write // Arrange/Act/Assert as comments but it should be clear where each step is happening. At the very least, leave an empty line between each of these sections.

If you keep this arrangement in mind, you will find it easier to follow good testing practices and split tests correctly by behaviour. All tests should have an action and an expectation, not all require setup.

Abstract out large "Arrange" blocks

Keeping data setup areas short is a good way to improve readability. Nobody wants to look at large blocks of constuctors/initialisers. Importantly, it should be clear what is different about this data compared with the next test in the class.

To keep arrange steps short and clean, feel free to create extension methods or other helper classes to carry out frequently performed data creation strategies.

In Summary

Unit tests should be clean and simple. Most importantly, they should clearly define the action or scenario, and the expectation.

Remembering this will ensure that your tests are useful, easy to maintain, and help to document your code.

Writing Good Acceptance Criteria

2021-10-01T01:30:00.003+00:00

As discussed in my last article, Writing good Acceptance Criteria gives the Agile team clarity and helps them work towards a common goal, saving time and effort while increasing quality. Now I'd like to dig into the details of how to write good Acceptance Criteria.

Behaviour Driven vs Procedural Driven Mindsets

Many of us may be used to writing/seeing procedural driven tests; step by step instructions with actions and expected results. Procedure-driven tests are often imperative and trace a path through the system that covers multiple behaviors. As a result, they may be unnecessarily long, which can delay failure investigation, increase maintenance costs, and create confusion.

Acceptance criteria, and indeed Behaviour Driven tests, should instead be behaviour driven.

This means they should be Declarative, specifying how a system should behave in a particular scenario.

Procedural/Imperative:

Given the user opens a web browser
And the user navigates to "https://localhost/mysite/"

Behaviour Driven/Declarative:

Given a web browser is at the local home page

As a result of this declarative mindset, a behaviour should have a one to one relationship with scenarios, meaning we don't have multiple expectations of behaviour from a single scenario, which would be easy to do with the procedural mindset:

// BAD EXAMPLE - covers 2 scenarios

When the user enters "cats" into the search bar
Then links related to "cats" are shown on the results page
When the user clicks on the "Images" link at the top of the results page
Then images related to "cats" are shown on the results page

Given, When Then

Acceptance Criteria should be written in the Given, When Then format. The reason for this is that each of these steps has a specific purpose. Respect the order of these, if you move them around, the criteria may not be clear.

Given

Given defines the prerequisites for the scenario, which screen we are on, and which data already exists. As it sets up state, it should be written in the present perfect tense, eg:

Bad: Given the Administrator navigates to the User Search page

Good: Given the Administrator is on the User Search page

When

When indicates the action being performed. It should therefore be written in the present tense, eg:

Bad: When the Administrator filtered the Users by name "Smith"

Good: When the Administrator filters the Users by name "Smith"

Then

Then is the assertion, it verifies the new state that is a result of the When action.These are better written in the present tense, because using the future tense reinforces a procedure driven approach, treating the scenario as a time sequence.

Bad: Then users containing the name "Smith" will be shown on the results page

Good: Then users containing the name "Smith" are shown on the results page

Write full sentences

Subject - Predicate - Action

It may tempting to leave parts of speech out of a step line for brevity, especially when using Ands and Buts, but partial phrases make steps ambiguous. For example, consider the following:

// Bad Example 

Given the user navigates to the Google home page
When the user entered "cats" at the search bar
Then the results page shows links related to "cats"
And image links for "cats"
And video links for "cats"

Writing steps without a clear subject and predicate is not only poor English but poor communication.

Test Cases

Acceptance Criteria should cover the main scenarios which will be faced by the new functionality. They are not a full breakdown of test cases. Developers writing unit tests can cover edge cases and paths through the code, while QA can apply a broader, more exploratory approach to the new feature.

If you find yourself creating lots of different Acceptance Criteria, it might mean that the job needs to be broken down.

Summary

The Given, When, Then format may seem verbose, and all this talk of correct grammar might sound scary, but writing Acceptance Criteria this way is quite easy. Think of each Acceptance Criteria as an action with an expected result - and then add prerequisites (the "Given") only if required.

Use of the correct tenses is something that just comes with practice and is not super important, it just helps to prevent you falling back into the procedural mindset. It's more important to write full sentences and follow the Given/When/Then, or Prerequisites/Action/Expectation format.

Following this format sets a standard which all jobs can follow, bringing consistency and clarity to tasks. It ensures that the required expectations are met, and gets the team thinking about all the actions that need to be performed.

What's the best gaming controller?

2021-09-24T15:10:00.009+00:00

I've tried all the game controllers. They all have such major pros and cons. If someone could put all the good features into one controller, it would be amazing.

Xbox

I owned the Duke, and I didn't mind it, but I have decent sized hands and it still felt like a bowl with buttons so when they brought out the newer controller I felt it was a good move. Ever since then Xbox controllers have been the most natural, comfortable controller out there, without question. I had a 360 controller for over a decade and a half across the Xbox 360 and PC, and it just worked.

I love the concave thumbsticks, I'm cool with the offset sticks, the buttons have always felt solid and the triggers get smoother with every release. It's a solid controller in every way, the D-pad on the new Series S controller is clicky but robust, the whole thing is comfortable and high quality. I love the Xbox controllers. They are now, however, missing some significant features.

Switch

What can I say. They are clunky, laggy, and overpriced, but you have to love them. It's the compromises that makes the Switch so charming, and you really can't compain about the joycons given what they contribute to the Switch's portability. It's a shame that the motion sensors are so underused.

Switch Pro

It just can't compete with the Xbox and Playstation and doesn't even want to try. It's much better than the the joycon but it's still just a cheap Xbox imitation.

PS5 Dualsense

I was always a fan of the Playstation controllers and enjoyed their skinny form. The PS5 controller however is a little bulky and it surprised me that they would do that after 4 generations of the skinny form factor. It's not the worst thing in the world but I did find myself distracted by its thickness from time to time.

My other major complaint with the Playstation controllers, and it's a big one, is the convex thumbsticks. I don't know if it's the material or just because I sweat 😅 but I found myself slipping off them often, frequently causing me issues in game. No such issues with the concave Xbox thumbsticks.

A minor but significant complaint is the positioning of the D pad. I realise this is a long standing Playstation custom, but the reality is, in this day and age, the D pad feels out of place where it is, because it's something that's no longer significant in games. Maybe it's just me and my 15 years playing with an Xbox controller, but hey, Nintendo (the makers of the centre stick N64 controller) decided to follow Xbox for a reason.

However, the innovation in the Dualsense is unmatched. Playing Astro's Playroom was one of the most significant moments in my gaming life - because of this controller. And it's not just the tactile triggers, which are absolute game changers in the world of gaming controllers, but also the sound, light and vibration which all genuinely add to the immersion of the game, setting this controller far ahead of all the rest. No other controller out there uses the sound and light to such immersive effect.

It also has a touchpad, and motion sense. It's the one controller with absolutely everything.

I really think that more time needs to be spent talking about those triggers. The way that they tense up, and then release, and how that adds to the immersion, is an absolute joy. Maybe because its paired with some vibration and joypad sound, I'm not sure, but they make the game seem more real, more physical.

If you haven't tried the Dualsense triggers, you are missing out on a whole other dimension of gaming. I'm sure the other controllers will copy this feature soon. Until then, the PS5 will have a huge advantage.

The Importance of Good Acceptance Criteria

2021-09-23T06:57:00.007+00:00

Acceptance Criteria can be seen as a chore, a convoluted, verbose set of prose with the sole purpose of satisfying "the business". At best, its value is underestimated and it is often written as a vague list of requirements.

Given the right attention, Acceptance Criteria can be extremely valuable to all members of a Scrum team. Before it can be done correctly, we have to understand its value.

So what exactly is the point of Acceptance Criteria?

Purpose of Acceptance Criteria

To define boundaries

Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired.

To reach consensus

Having acceptance criteria synchronises the development team with the client. The team knows exactly what conditions should be met, just as the client knows exactly what to expect from the developed functionality.

To allow for accurate planning and estimation

Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.

To serve as a basis for tests

Acceptance criteria provide a good baseline for writing tests. Test cases can break down Acceptance Criteria to go into more functional detail, and to cover edge cases.

Acceptance Criteria helps the team deliver quality

Acceptance Criteria is vital for delivering quality. If done correctly, it can simplify development and guide a comprehensive testing strategy. It is the glue that holds requirements together.

Acceptance Criteria is valuable to all stakeholders; Developers, QA, Product Owners, and the team as a whole. How it helps each stakeholder, however, varies according to their role.

Good Acceptance Criteria

How it benefits Developers

Good Acceptance Criteria gives developers clarity and allows them to break down their tasks into manageable pieces of functionality. With visibility of all possible scenarios, good Acceptance Criteria actually allows optimum design of the code. It enables developers to structure their code in a way that best meets the requirements. The code can be written around each scenario, ensuring each criteria is met in the simplest way possible.

The clarity given by good Acceptance Criteria keeps the business requirements at the forefront of the developer's mind, helping them to avoid getting bogged down in technical details which may not be conducive to the task.

How it benefits QA

Good Acceptance Criteria can guide QA in generating test cases and any required test data. With clear, simple scenarios, QA will have a solid base for test cases, and can then focus on expanding the Acceptance Criteria to cover edge cases.

Without clear, broken down Acceptance Criteria, it can be hard to work out test cases. If this happens, certain scenarios might be missed, and the important expectations of the job might be overlooked.

How it benefits the team

Good Acceptance Criteria helps get all the team on the same page. It aligns everyone with common goals, and helps them work together to build out the requirements. This collaboration is important and often overlooked.

Development and QA can come together at the start of a task in order to work out what needs to be tested. This allows Development to perform some degree of Test Driven Development. Even if it isn't possible to write automated tests before the code, the developer will at least have a good idea of what those tests are going to be before writing any code.

QA can guide this process, elaborating on what they will be testing, helping to set up test data, and informing the developer of possible edge cases to watch out for.

If the Acceptance Criteria is missing anything, the Product Owner can be questioned for more details before the work commences. Without clear Acceptance Criteria, there is no way of knowing if there are any missing details.

Good Acceptance Criteria can make a difference

With good Acceptance Criteria, the team is able to see, at a glance, what is required from a task. It provides a consensus for the whole team which aids both planning and delivery.

Good Acceptance Criteria helps developers come up with cleaner code. It makes testers' lives much easier. It helps the team come up with the best Automated Testing solutions, which is vital for Agile projects. It helps the team plan the best possible approach, and avoids stumbling into questions mid-development.

Don't underestimate the value of good Acceptance Criteria. It can increase productivity, collaboration, and quality.

In Coding, Nothing is Trivial

2021-02-16T11:34:00.003+00:00

Imagine you're reviewing some code, as part of a Pull Request, and the developer has misspelt a variable. Or added a magic string instead of a constant. Or put the expected/actual parameters in an assertion the wrong way around (although it kinda doesn't matter because they're the same)?

You can politely comment on it, and perhaps they will fix it up. But sometimes you might be met with resistance.

"It's not that important."

To a degree, they're right. These are pretty trivial observations. There are probably bigger things to address, such as the logic, the architecture, the test coverage etc.

However, in coding, these trivial issues tend to come back to bite you, either as bugs, or as maintenance headaches.

You don't want to nag people. You don't want to become a "clean code nazi". But you can firmly assert that you think a mistake is being made and that a potential issue could arise.

There are some things in coding that are a personal preference. There are some things that are virtually (though not completely) insignificant and which you should avoid fighting about (tabs vs spaces) and then there are things which actually matter. The lines are blurred and you should always be pragmatic - but the things which actually matter can be proven to matter - a misnamed variable can cause confusion, expected/actual parameters the wrong way around can lead to false positives in your tests, and magic strings can lead to runtime errors, code duplication, and mysterious bugs that can really mess up your day.

What's important is that you communicate these issues when making your suggestions. Make it clear that this isn't a personal preference thing - it's not you being fussy, but that it could lead to genuine problems.

The main reason that many of these "trivial" issues can lead to serious problems is maintainability - other developers working on the code. Maintainability is just so important - not having it leads to bugs, slow development, demoralised developers and more. Anything that affects maintainability, isn't trivial. Its effects are amplified because of all the people that become involved in the problem.

When you have maintainability problems, you get bugs. It doesn't take much to turn a badly named variable into a half day investigation and a costly Production change.

So, raise your standards. Don't settle for "It's not that important". If you have an issue with it, if it niggles at your brain even slightly, it's for a good reason. Your subconcious can spot a time bomb. Trust it.

Writing Good Acceptance Tests

2020-11-24T00:56:00.006+00:00

Acceptance tests can be used to verify end to end functionality in a way that is understandable to the business. They are very broad compared with unit tests, and when automated via a tool like Specflow, are based on a more natural language. It's important that we use this natural language to keep tests simple and concise, rather than trying to write long-winded "functional" tests.

Good Gherkin

Before writing Acceptance tests, learn about Acceptance Criteria Best Practices. The ability to write good Acceptance Criteria translates directly to Acceptance testing. They both follow the same standards and they can be written in the same way.

We should attempt to apply these best practices apply to Acceptance tests as much as is practically possible, especially when it comes to grammar as this helps us stick to a standard.

The most important thing is to remember that Acceptance tests should be written with the Given, When, Then syntax where:

Given sets up a state,
When is an action,
Then is an assertion.

Every test should have an action and an assertion, and most require some kind of prerequisites. This ensures that the outcome of actions are actually being tested, and maps directly to a test case.

Let's reiterate a couple of points.

Given should be used to set up pre-requisites. It should not be used for actions, for example "Given I navigate to the admin page". You can however say "Given I am on the admin page" which achieves the same thing but keeps the structure clearer.

Likewise, Then should not be used for actions, such as "Then I delete a record". Then is for assertions, for checking the state of something that was changed by the "When" directive.

Remember to be careful when using AND that you don't break these rules. For example, don't say

"WHEN I delete a record THEN I should have a record AND I click exit"

In this case, the AND is now a "When", not a "Then". In other words, AND should be the same as the preceding directive. In the above example, as it is not an assertion, it should be a "When", and you probably want to follow it with another assertion "Then".

It might sound like I'm picking on grammar here but the point is that the 3 directives serve different purposes - the point of a test is to ensure that an action has an outcome. Mixing up their use means that you may not be creating an actual test case, but rather running through a series of steps, and you may not even have any assertions.

Focus on business actions rather than functional sequences

Practically speaking, in many Acceptance tests there are usually a lot of When steps, or actions performed. However, where possible we should strive to make all End to End code as concise as possible. Writing Specflow/Cypress that does several steps on one line is OK if each of those steps make up a single functional action.

For example, rather than

When I populate the form with the following values: | Field | Value | And I click the "Save Changes" button

We could just say

When I save the following values:| Field | Value |

and have the underlying code also click the save button/save the changes.

The best way to think about this is we should be more concerned with business actions, or feature functionality, than stepping through a sequence of button clicks.

Avoid multiple When/Then repetitions

One test, one behaviour, where possible. Any more and you're really testing multiple criteria, and each test should be testing one scenario (hence the Specflow keyword "Scenario").

Of course with Acceptance tests having such a high overhead, you might still want to do multiple assertions from time to time, but use it sparingly and be aware of it.

Use Background steps

A background step happens before every Scenario in a feature file. Use it for setting up data. Then your tests can be clean and start with a simple "Given I am on the Search screen".

If you need each scenario to have different data you can put the data setup Given steps in each test, but in this case you might want to consider why there is different data for each test, and perhaps you need to move the tests into a different feature file.

Avoid testing logic

It can be tempting to test lots of different scenarios with Acceptance tests. I am speaking from extensive experience when I say: this will make your life very difficult. Acceptance tests have high overhead and can be extremely flaky.

Acceptance tests are for testing high level End to End functionality. They should not be used for testing intricate business logic. This should be done by Unit and Integration tests.

If it is too hard to write Unit/Integration tests, you may need to look at making your code more testable and addressing technical debt.

A large part of avoiding testing the logic comes down to testers and developers working together. When this happens, you can avoid a situation where the testers may write a dozen Acceptance tests which just test the same code path with different variables - not valuable from a quality perspective and also adding a huge unnecessary overhead to the testing time and maintenance.

When working together, developers and testers can come up with a strategy where the logic and edge cases are covered by unit/integration tests, while the basic Acceptance Criteria/end to end connectivity/functionality can be verified by a small number of Acceptance tests.

Don't write too many Acceptance tests

Acceptance tests are known for being flaky and unreliable. They can also be hard to maintain. Keeping the number of tests low makes them easier to manage.

Acceptance tests can provide tremendous value by verifying End to End functionality, but people need to be able to trust them, so keeping them easy to maintain is key to keeping them reliable.

Clean coding Tips: Access Modifiers

2019-05-08T05:56:00.005+00:00

It seems to be by default that classes, methods, etc are created with the public access modifier.

This is not actually the case, the default is internal class/private members, but public seems to be the de-facto choice by a lot of developers.

If you're creating a public class - you have a big responsibility. Your code can now be used by anything else in the application, or even outside it. This means if you change the internal working of it, you will affect everything that uses it - and you have no control over what that is. This means a couple of things.

Naming is always super important

Naming of public classes and methods and their expectations should be crystal clear. Don't rely on comments to convey intentions. It must be highly obvious what the class is for, what it does, and how method parameters are used. It should be specific and adhere to the Single Responsibility Principle - one reason to change. If someone comes along and adds a parameter to one of your methods to get it to do something else, this is an indication that the class's purpose was not clear enough.

If the naming is not clear, the purpose gets diluted, and the class will be modified away from its original intentions. This causes code to bloat and become more prone to bugs.

Tip: This is yet another reason to avoid "generic static helpers"! If your classes or methods are public, tests need to cover every possible way that the code can be used - every single path. What this means is that anyone using the code will know exactly what is expected of it because its functionality is documented by tests. Any usage of the code will already be covered by a test.

If you don't create tests, anyone can come along and change this code which can then affect any number of consumers.

Don't make life hard for yourself

Don't want this responsibility? Simple: Don't make your classes and methods public. Of course internal members should always be tested and code should be named well. But these issues take on less importance if the code is isolated.

Go with the lowest access first and only open it up as and when you need to, When you do open it up, make sure that it does what it says it will, and it is fully tested. The important thing to remember is that when a class is public, it increases its exposure, which allows it to be coupled with more code. This is a significant cause of spaghetti code and regression issues as the code is maintained.

Keep code restricted to where it is needed. If it needs to be public, it needs to be robust.

Why should I care about Quality? I'm a developer!

2018-10-05T12:55:00.003+00:00

OK, no developer wants to create bad quality code. But for most developers, quality is seen as something separate from development, something that is checked after the work has been done. It is something that QA do, after you throw your code over the fence. Thinking about quality at during development is a burden, slowing down the creation of functionality, holding up new features. Thinking about quality before development, well that's just crazy talk.

Old Habits Die Hard

In the Agile world, this is starting to change. Quality is being baked into the development process and there is more interaction between development and QA during the development phase. At least, that's the theory. In practice, we often slip back into bad habits of throwing code over the fence.

The reason we keep falling back into bad habits is because the attitude around quality is the same as it always was. It is still seen as something separate from development, separate from design, separate from planning. This causes it to be seen as a burden - extra work that just has to be done.

Quality as the Glue

If instead we change our perspective, and try to see Quality as an integral part of the entire development process, it can change the way we all work, from developers to product owners. Instead of a burden, quality should be a thread that runs throughout the process, and actually defines how all work is done from the ground up. If this is done, it can actually simplify and speed up development.

Baking quality into your process shifts the responsibility to everyone, rather than just QA. Having the whole team (including product owners) take responsibility for quality sets the focus around Acceptance Criteria. This "requirements-centric" approach gets everyone thinking about quality right from the refinement meeting. When the entire team comes together and builds good Acceptance Criteria, quality becomes a natural, and welcome, part of the development process.

Several things then happen. First, the whole team are forced to agree on the details of the requirements before development starts. Before any technical decisions or implementation planning, the exact requirements are clarified. Only by making this an imperative part of the process (usually the refinement meeting) can this happen effectively.

Good Acceptance Criteria Drives Good Development

With clear Acceptance Criteria, development is simplified. Development knows exactly what they need to implement, and when they know this, the process of writing automated tests is no longer abstract and difficult. Test Driven Development is a tricky thing to do, in practice. However, with clear goals, a developer can start with "pseudo tests" - tests which are just code comments - but which outline the business logic before coding begins. These will be a granular list of Prerequisite/Action/Assertions - Unit tests, essentially - outlining the required logic. Then, development becomes a process of implementing that logic.

Breaking the logic down before development begins is a very effective way of ensuring that clean code practices, especially the Single Responsibility Principle, are followed. It becomes natural to keep the logic simple, concise, and separated from other concerns, such as infrastructure. It encourages clean Object Orientated design.

Good Acceptance Criteria Drives Good QA

Also QA know exactly what they will be getting. They know what parts of the job will be automated, so they can design better integration, acceptance, and End to End tests, as well as an effective exploratory strategy.

Without this clarity, QA are left with waiting until a job is done and not knowing what they're going to get - which is a recipe for annoying manual regression testing, and no doubt, bugs.

Agile Demands Quality, Quality Brings Clarity

Agile is about iterating fast. You cannot do this when QA are held back by a requirement to constantly manually regression test, or worse still, you avoid regression testing and hope new development doesn't break anything.

With good Acceptance Criteria baked into the process, everyone has clarity. As a developer, this makes your life so much easier. You know what needs to be developed before you start, which allows you to concentrate on technical implementation details. With clear requirements, the code is cleaner, so development and maintenance is easier. This allows the team to iterate fast, able to add new features quickly.

Early automated testing becomes a breeze, and with this automation in place, QA can focus on exploration. With automation, we are able to develop with confidence, and innovate freely.

Quality no longer slows down the development process, but guides it.

That's why developers should care about quality.

Being a Senior Developer is more than being a long serving developer

2018-04-08T22:03:00.024+00:00

Like many people, I started my development career from another role. I taught myself coding and then built software to help the business and myself. It was well received, but I did not feel like a "real" developer yet.

This experience convinced me that software was what I wanted to do, so I looked for a junior developer role. This wasn't easy, most companies want people who can come in and start being productive right away, and there were many skills I lacked from not working in a "true" software development environment. Eventually, after much persistence, I was taken in as a junior developer for a large finance company.

When handing in my resignation to my non-dev-shop company, I was offered a pay rise to more than I would be getting in the new role at the finance company. I was also offered a new position, the position of "Senior" developer.

Now I had a choice. I could stay, and drive development projects, leading a team of newly hired junior developers. My career would leap to a role of seniority and if I was to move on I could say I had been a "senior" developer.

Or, I could move into a new company as a junior developer, where I would be mentored, and surrounded by more senior developers.

I chose to move.

I wanted to see how it was"really"done. How developers work together, how they feed off each other, how they learn. I wanted to learn. I could not do that if I was the most senior developer.

Staying was never an option. I'd be a fraud. The title of senior can be extremely subjective, given for many reasons. Tenure, age, comparative skill, or genuine skill.

Yet I see this often. Developers who have always been a senior developer don't get to see how it's "really" done, how skilled software departments work together. You can't always work out the best ways to do things by yourself. You need exposure to different practices, methodologies, cultures, personalities, and skill levels.

Moving to a junior role was the best thing I ever did for my career. It taught me to understand the development process from the ground up, filling in many skills gaps from being self taught. Some of these skills were technical, some were interpersonal, but the most important, were both.

Now I realise that the maintainability of our code is one of our most important skills as a developer. It's often said that we write code once and maintain it ten times. Most importantly, other people maintain it. If your code isn't maintainable, then bugs happen.

If your code is not maintainable, it can bring down companies.

Senior developers who have always been senior may not learn the importance of maintainability. They never have the pleasure of being told off by more senior developers for sloppy, non-reusable code. They didn't have the privilege of being humble and being shown how to write code that others can work with. Nobody complains to them about their code because they are always more senior. So they tend to get away with it, and often end up in charge of a hard-to-maintain monolith that nobody wants to work with.

Senior developers should recognise that without exposure to different working dynamics, or other developers who have worked in different environments, they may be missing out.

Management should compliment in-house, home-grown senior developers with senior developers who have experience where they were not the most senior. Well rounded senior developers with a broad range of experience, who are not afraid to speak up when code is not written with others in mind.

If I had stayed as a "senior" developer, I may never have learnt the value of writing code for others. And I may not even have realised it.

Ways to Spot Single Responsibility Violations

2018-03-26T03:23:00.000+00:00

Classes should only have one reason to change. We should attempt to increase cohesion between things that change for the same reason, and decrease the coupling between things that change for different reasons. Classes should do one thing and one thing well.

Violations of the Single Responsibility Principle can cause code to be difficult to test and maintain, and can make it easier for bugs to manifest.

There are a few symptoms of SRP violations which can give warning signs of these issues.

Large classes/methods

Obviously large classes and methods do not always point to SRP violations as there may be a requirement for a significant amount of logic. However, it is usually a good sign.

Large methods are more likely to point to an SRP violation than large classes, or at least too much cyclomatic complexity. You'll become aware of this when you attempt to cover the method with test cases, and realise there are excessive test combinations required.

Too many injected dependencies

While this may depend a lot on how you set up your services, lots of injected dependencies may suggest that the class is doing too much, and may be violating SRP.

Too many tests per class

If a class has too many tests, or the tests need to change often, this is an indication that there may be too much complexity, too much setup, and this may point to an SRP violation.

Described with and/or, or encompassing words such as "manager"

This is a sure sign that your class or method is doing more than one thing. For example: a method called CreateOrEditRecord() or a class called "InvoiceHandler" are red flags, and should be investigated.

Logic in Views

Logic in your front end almost always means that you are violating SRP, because a view's responsibility is to render an output. As soon as you have two pieces of logic in a view, it's unlikely they'll be for the same reason, because they'll be for different elements on the page. This immediately makes it impossible to unit test the view.

Also, because of the standalone nature of views, there's a good chance you'll have to violate DRY in another view.

Move that logic up to a model, a controller, a helper, or a service where it can be properly unit tested.

Microsoft Certified Solutions Developer!

2015-12-17T10:57:00.000+00:00

After 3 years, 3 exams, and an excessive amount of study I have achieved the Microsoft Certified Solutions Developer - Web Applications certification.

I realise that many people don't put a huge amount of emphasis on exams, valuing real world experience instead. But I have found that what I learned studying for these exams has been extremely valuable to my profession, helping me make more informed decisions in my day to day work.

There is no substitute for real world experience, but real world experience leaves a lot of gaps and doesn't always teach the best habits. The exams have enabled me to fill in these gaps and develop a real technical proficiency which I may not have had without them.

Update:
Born to Learn just posted this blog talking about a recent study which found 4 advantages certified staff have over non-certified staff, there are some interesting findings! https://borntolearn.mslearn.net/b/weblog/archive/2016/01/25/four-solid-reasons-to-hire-certified-employees

Amazing Things You Can Do With Azure Storage Queues

2015-10-27T20:50:00.001+00:00

Load Balancing and Workload distribution

Queues can be used to organise the distribution of a workload across multiple processors.

A common technique is to post messages to a queue which are a key to a task which needs to be performed, and have multiple worker processes pick these tasks from the queue to perform in parallel.

This can be combined with other storage mechanisms to perform complex tasks. Say you were trying to render an animation. The queue could be loaded with keys, which point to an entity in Table storage. This entity could contain the Url of an image stored in blob storage. A worker process would pick up the message from the queue, reference the entity from the table and download the image from blob storage. It could then perform compute intensive tasks on the image while other worker processes picked up other images.

In this way, cloud storage can be used to augment worker roles and perform powerful parallel operations.

Asynchronous Processing and Temporal Decoupling

It might sound like something you do with a sonic screwdriver, but temporal decoupling simply means that senders and receivers don't need to be sending and receiving messages at the same time. With messages stored on the queue, they can be processed when the receiver is ready to do so, and the sender is not held up.

This can be useful for performing background tasks which are not critical to the main operation of a program, for example, a web application, rather than providing a slow response, can just queue up a thumbnail generation process and respond to the user quickly. A game, which requires the utmost UI responsiveness, might store replay data asynchronously using queues.

Calling Long Running Methods Asynchronously

2015-10-05T22:28:00.000+00:00

When you are able to call an async method, do it using async and await or by making your method return a Task:

public async Task<string> RequestData(Uri uri)

{

WebClient webClient = new WebClient();

return await webClient.DownloadStringTaskAsync(uri);

} // Rely on underlying Tasks whenever possible.

public Task<string> RequestDataAsync(Uri uri)

{

WebClient webClient = new WebClient();

return webClient.DownloadStringTaskAsync(uri);

} // Rely on underlying Tasks whenever possible.

Dealing with synchronous calls

When the method you are calling is not asynchronous, wrap the method in a task delegate:

public Task<string> RequestDataAsync(Uri uri)

{

return Task.Run<string>(

() =>

{

WebClient webClient = new WebClient();

return webClient.DownloadString(uri);

});

} // Create Tasks when you have no other choice.

Capturing Exceptions

Getting a little more advanced, what if you might need to capture exceptions from a long running method? Use the following pattern:

public Task<string> RequestDataAsync(Uri uri)

{

var tcs = new TaskCompletionSource<string>();

WebClient webClient = new WebClient();

webClient.DownloadStringCompleted +=

(_, args) =>

{

tcs.SetResult(args.Result);

};

webClient.DownloadStringAsync(uri);

return tcs.Task;

} // Example of wrapping Async/Completed.

More info

Async'ing Your Way to a Successful App with .NET
http://channel9.msdn.com/Events/Build/2013/3-301

Creating Async Libraries That Are Modular, Reusable and Fast, in Microsoft Visual C# and Visual Basic
http ://channel9.msdn.com/Events/TechEd/Europe/2013/DEV-B318

NuGet Like a Boss: Part 1 - Don't Check in Packages

2015-08-20T01:26:00.001+00:00

After suffering like many with so many Package Restore woes in my projects I decided to make notes on the best way to deal with Nuget packages.

Ignore the packages folder

Not doing this means you check in the packages which are huge. This is annoying and kind of defeats the purpose of Nuget. When you ignore (and therefore don't check in) your packages folder, anyone getting your source code can run package restore on the solution and Nuget will download the packages automatically.

How?

First, add a file named .tfignore. This may require some Command prompt renaming as some set ups don't like files beginning with a dot. When you get past this annoyance, open the file in notepad and enter the following:

\packages

That tells TFS to ignore the packages folder. For some bizarre reason, this doesn't include the respositories.config file. You'll need to add a second line as follows:

!\packages\repositories.config

You'd think this would be it, but you may notice that your packages folder is already in your Pending changes. To get around this, create a folder called .nuget (command prompt trickery may be required) and in there create a file called NuGet.config. It must go in this folder, even if you have another NuGet.config at solution level. Enter the following text:

<?xml version="1.0"
encoding="utf-8"?>

<configuration>

  <solution>

    <add
key="disableSourceControlIntegration" value="true"
/>

 
</solution>

</configuration>

This should ensure that your packages stay out of source control.

Finally ensure that .tfignore and NuGet.config are added to source control so that these settings should apply for anyone using the project.

Gotcha!

Be aware that the .tfignore file may not work if someone has already checked in the packages folder. Delete this from source control and you should be good.

Developing for the Cloud - An Introduction

2015-08-10T22:22:00.000+00:00

When you create a web application for the cloud, there are many things that need to be done differently. It's not just a case of saying "I'm doing cloud" and all you're really doing is putting it on someone else's VM. Doing this, the costs are much higher than if the application is designed with cloud in mind. This might be fine from an infrastructure point of view, but the cloud can have profound impacts on development from the ground up.

Azure allows us, and also forces us, to engineer our applications completely differently.

Forces? Well, this is because when you're hosting in an App Service plan, you're billed based on compute time and resource usage. This forces you to write more efficient code. You can't just write code that performs unnecessary operations and get away with it - the efficiency of code now directly translates to dollars. This demands that you think twice when writing code, espcially loops, to ensure you're being efficient. Caching becomes a major priority so that you're not hitting a database unless you absolutely have to.

With the weight of costs, you need to start thinking about more efficient ways of doing everything. Luckily Azure offers many services to help increase application efficiency. The most basic example is storing images and other static resources in Blob storage. This is fast, lightweight, and extremely cheap.

Scripts and CSS can be offloaded to localised CDNs. This also increases speed and significantly decreases cost.

Some data can shift from SQL to NoSQL models such as Table Storage, DocumentDB, or Graph data with its powerful relational features. An application might use all of these data types simultaneously for different purposes. For example, a shopping cart site might use SQL to store a user's identity information, Table storage to manage their shopping cart, DocumentDB to store product details, and Graph data to build "You might also like" links.

Need to run asynchronous/background tasks such as generating thumbnail images? Use Web jobs to run scripts, executable, and third party libraries completely outside of the typical web application Request/Response lifetime. Use queues to decouple logic from the main workflow, or use multiple worker threads to perform parallel processing.

We can also take advantage of Azure Search (powerful search services), Service bus (host web services locally but expose them via the cloud), Azure machine learning (predictive analytics, data mining, and AI), and Notification hubs (push messages down to clients).

Then, we can host our applications in App Service plans (instead of Virtual Machines) and take advantage of Visual Studio Online's build and Continuous Integration features. We can also leverage elastic scaling and Application Insights.

There are many more features in Azure and more appearing every day.

To summarise, developing for the cloud is very different from building a website that will be isolated on a local server. It's a far more distributed model where separation of concerns is much more pronounced than we're used to. Developers and architects will need to think differently when designing applications.

This is just an intro to cloud features. In the future I will go into cloud architectural design patterns which allow us to design our applications to be resilient in failure-heavy environments.

How to Be an Organised Developer (and spend more time coding!)

2015-06-23T23:17:00.000+00:00

As a developer your main focus is to write code. But over time, you'll find that there is a lot more to development than this. If you're not aware of this, you might one day wake up and realise that the notepad file you used for passwords and connection strings has gotten out of hand.

Being more organised from the start can help keep you focussed on coding and help you stay more efficient. If you move jobs you'll pick up a lot of information in the first few weeks, you'll want to organise it well from the start. If you stay in the same job for years, the 'other stuff' you accumulate can get messy and cumbersome.

Like good code, making an effort to organise yourself well from the start can pay dividends later on, when it comes to navigating and maintaining all your stuff. Here's a list of some of the "stuff" you'll find yourself accumulating as a developer, and how to keep it well organised.

OneNote (or Equivalent)

An essential tool for all developers.

The main thing this is useful for is storing essential information such as test data, database names, licence numbers for tools such as Resharper and Linqpad, and lists.

You can also use it for debugging information, screen grabs, functional specs, checklists and pretty much anything you can think of. OneNote allows you to organise all this quite effectively with its use of tabs and pages.

Note that by "equivalent", I don't mean Notepad++. You need your notes in one well organised and secure location (save your notebooks remotely), you don't want to have to worry about hitting "Save", and you also need to be able to paste in screen grabs, tables and other rich content. Evernote might come close but OneNote is trusted in enterprise environments which can give it the edge.

Logging Access

Pretty soon you're going to need to access logs for auditing, testing or debugging purposes. Remember to record all details in your note software.

Product Documentation/Wikis

As a developer you will probably be responsible for writing a lot of documentation. Make sure it's in an easily discoverable place and well maintained. Good code should be self-documenting, yes, but other stakeholders need to know what the code is doing from a non-technical perspective.

Bookmarks

You'll always have a selection of really important links. This might include:

Product documentation/wikis
Test Harnesses
ALM tools (TFS, Git)
Communication tools (Sharepoint, Trello)
Administration tools (Timesheets, financial, personnel software)
Development learning materials, tutorials, blog posts, communities etc.

Figure out the best way to organise these based on your needs and make sure they're backed up and accessible everywhere (use Chrome/Firefox Sync or a bookmarks manager).

SQL Files

Most developers will probably have a collection of SQL files of common, useful queries, for logging, basic CRUD, etc. Make sure these are in an easy to access, secure, backed up and preferably remote location.

Macros

Specifically in Web Development, tools such as iMacros can be invaluable for automating frequent tasks such as logging in to test sites or running common actions on test harnesses. Remember, keep them well organised and backed up remotely using Dropbox/OneDrive etc.

Powershell Scripts and batch files

You might also have some PC management tasks that need to be automated. Powershell is fantastic for these kind of tasks, and is becoming even more useful with the advent of DSC.

Linqpad Scripts

Similarly, Linqpad allows for frequently used code to be stored and used in a lightweight manner without all the project overhead.

Code Toolbox

Finally, all developers should have a code toolbox, or a collection of libraries and code snippets they use regularly in their projects. This is a lot to go into so I will create a new blog on it, but basically it could consist of

Project templates
Emailing library
Cloud storage library
Logging classes
MVC Html helpers etc

The idea is to allow for Rapid Development by having everything you frequently need at your fingertips and not having to worry about finding code for frequently performed tasks such as input forms or membership features. As I said, I'll give this topic a blog of its own soon.

Conclusion

Hopefully this has inspired you to ditch that pile of text files and get your administrative stuff in order. Doing so will make you more efficient and help you focus on what's really important - writing code.

How do you organise yourself? Is there anything I've missed? Leave a comment!

Why Bother With Unit Tests?

2015-05-29T05:36:00.001+00:00

I still see a lot of scepticism on WHY we should do Unit Tests and if they're really worth it.

Of course, they usually add time to the development cycle. They can be hard to create. Quite often, they seem pointless; Why do I need to check if my TwoTimesTwo() method returns 4? Of course it's going to!

Well, the benefits of Unit Tests may not always be obvious. Often they're disconnected from the problems caused by not doing them. For example, a manager is not likely to blame a Production issue on the fact that you didn't do Unit tests.

Most of the time, if you release some code that performs what it needs to, nobody cares about the quality. However, the people who will care, are those who want to maintain your code later, especially if it ends up being:

You; or
A violent psychopath who knows where you live

Unit Tests can also help to document code, showing you what it should and shouldn't be doing. They can help you understand it better.

But maintainability still isn't enough for many people.

Personally I don’t think anyone can really understand the benefits of Unit Testing until they've written some, and felt the satisfaction of those green ticks, and the confidence they give you. Your code is now rock solid, nobody is going to break it without knowing about it (including yourself).

With Unit Tested code you can be sure that every component is doing what it should be. Acceptance Criteria is another step and I'm a strong proponent of automated behaviour driven integrated tests too. But Unit Tests can be more granular, covering a vast array of tiny details that can otherwise be easily overlooked and become the source of fiddly bugs later on. Also, when bugs are found, usually this results in messy, band aid fixes which make the code less flexible. TDD makes the code more maintainable to start with. The necessity to write SOLID code is increased by the need to ensure the code is highly modular and interface driven.

In the end, the extra time spent building unit tests is returned several times by spending less time fixing bugs and maintaining messy code.

The best way to see the benefits of Unit Tests is to write some. Start easy by writing one specifically to test a bug fix. You can then be sure that bug will never surface again.

Getting started is hard, don't get me wrong. It's like lifting weights for the first time, it's going to hurt. But push through the pain and you'll start to see the benefits. It will get easier.

The Idea is the Easy Part

2015-04-01T09:07:00.000+00:00

Most people are of the belief that coming up with an idea is hard. “If only I could think of an idea, I’d be able to create a business”, they say.

They also try and think too big. They hold out for that “killer app” or world changing concept. The next Facebook.

But business ideas don’t have to be that ambitious. And they certainly don’t have to be that difficult to come up with. All you need is this simple formula.

Idea = Niche + Need

Find a niche, find a need. It really is that simple. But let’s dig into it some more.

Find a Niche

A niche is a small area of interest. A specific area of the market for people with a specific interest.

Finding a niche is a balance between finding a market small enough to be focused but large enough to be worthwhile.

Finding the right niche can be difficult in itself, but it can be made easier by following what interests you. This is actually incredibly important. Focusing on an area that you’re passionate about will both inspire you and keep you involved when things get difficult.

Getting to know a niche will allow you to develop mastery, and this alone can open up many business opportunities. However, your skills don’t necessarily have to correspond to your niche. In fact, bringing fresh skills into a niche can open up plenty of opportunities on its own. For example, you could be an app developer interested in gardening, or a designer who enjoys surfing.

Find a Need

Once you have a niche, spend some time in it. Ideally you’ll already be doing this and will have been for some time. It’s a hobby, better yet a passion. You might even be working towards becoming an expert in some aspect of your niche.

The better you know your niche, the better you’ll be at seeing needs within it. It won’t be difficult, in fact you’ll probably become aware of so many needs that your problem will be choosing one.

You’ll have to weigh up what kind of resources are required, what is going to be easy to rapid-prototype, what could be profitable, and what area you have sufficient knowledge in. This is probably the topic for another article but for now, you should have no shortage of “ideas”. Remember, the idea doesn’t need to change the world. It just needs to fulfill a need.

So again, coming up with an idea is not “the hard part”. If you focus on a niche that interests you, spending some time getting to know it, learning its ins and outs, and perhaps becoming an expert in it, you should be able to identify plenty of needs.

Then it’s up to you to choose one that you’re in a position to fulfill.

How to Reduce Deployment Risk

2015-03-20T01:16:00.002+00:00

Functionality Switches

Feature flags controllable by configuration or an "admin tool", are an excellent way to deploy new features. When going live, you can turn on a feature only for your Production test user, and run some smoke tests, before turning the feature on for the wider world.

Any issues found later can then easily be mitigated by "switching off" the broken features for live users, while at the same time, leaving them on for the test users so that some fault investigation can be done on Production.

Providing there are no breaking regression changes, this will help to avoid rollbacks.

Good logging

Every significant action should be monitored and logged. Obviously this includes calls to external services, but you should also strive to implement logging based on items in the Acceptance criteria. Log results of actions so that you can see if they match expectations. This allows for granular diagnosis so you can see exactly what isn't working and where.

Reduced Functionality Instead of Errors

A good, defensive technique is to fall back to previous functionality when something fails, rather than giving the user an error. Obviously this depends on the scenario and this won't always be possible.

However, combined with functionality switches, this can allow users to continue to use your application while you identify a fault using your production test users. This is also greatly dependent on your logging, of course, as your fault will not be manifesting in the interface.