A collection of my thoughts and learnings. Hopefully some of it will help you.

A collection of articles and blogs on various topics that my clients and colleagues may find useful or interesting.

My thoughts

In the world of digital innovation, bringing a new product to life is an exciting journey. But let's face it – it's also a complex process that can quickly become overwhelming without proper planning. So, how do you navigate it and turn your brilliant idea into a successful digital product? Let's explore the art of planning your digital masterpiece.

The Blueprint: More Than Just a Pretty Picture

First things first – you need a plan. Think of it as the blueprint for your digital skyscraper. It's your roadmap, your north star, guiding you through the twists and turns of product development. But here's the kicker: your plan shouldn't be set in stone. The digital world moves fast, and your plan needs to keep up.

Imagine you're planning a road trip. You've got your route all mapped out, snacks packed, and playlist ready. But what happens when you hit unexpected traffic or discover a cool detour? You adapt. The same goes for your product plan. Be ready to take a few scenic routes along the way.

Know Your Audience: It's Not You, It's Them

Before you start building, take a step back and really get to know your audience. Who are they? What makes them tick? What problems keep them up at night? This isn't just about creating user personas – it's about developing genuine empathy for the people you're building for.

Here's where things get interesting. You might think you've got it all figured out, but trust me, your assumptions will be challenged. And that's a good thing! Let go of your ego and embrace the unexpected. Your users might surprise you with insights that completely reshape your product vision.

Prototype: Your Product's Dress Rehearsal

Now that you've got a clearer picture of your audience, it's time to give your ideas a test run. Enter the prototype stage. This is where your product gets to try on different outfits and see what fits best.

Tools like Figma or Adobe XD are your backstage crew here, helping you create a visual representation of your product. But don't get too caught up in making it perfect. The goal is to create something tangible that you can put in front of real people.

Your prototype is like a conversation starter. Use it to spark discussions with potential users, investors, and team members. Their feedback is gold dust – it'll help you refine your ideas and avoid costly mistakes down the road.

With insights from your prototype in hand, you're ready to build your Minimum Viable Product (MVP). Think of your MVP as the heart of your product – the bare essentials that solve your users' core problems.

It's tempting to pack your MVP with every cool feature you can think of. Resist that urge. Keep it lean and mean. Focus on solving one problem really well rather than addressing multiple issues halfheartedly.

But here's the clever part: while you're keeping things simple on the surface, make sure you're building in ways to learn from your users. Integrate analytics tools that let you peek under the hood of user behaviour. Set up easy ways for users to share their thoughts and experiences. The more you can learn at this stage, the smarter your future decisions will be.

Launch and Listen: The Real Journey Begins

Launching your MVP isn't the finish line – it's the starting pistol. This is where the rubber meets the road, and you start to see how your product performs in the wild.

Pay close attention to how people are using your product. Are they using it the way you expected? Are there features they love that you thought were minor? Are they struggling with things you thought were intuitive? Let the data and feedback guide your next steps.

Don't be afraid to change course if needed. Remember that road trip analogy? Well, now's the time to be ready to take those unexpected turns. Your initial plan was a great starting point, but now you have real-world data to work with. Use it wisely.

The Never-Ending Story: Continuous Improvement

Here's a secret about successful digital products: they're never really finished. The most effective product teams embrace a mindset of continuous improvement. They're always looking for ways to make their product better, more useful, and more delightful.

Stay connected with your users. Create opportunities for ongoing dialogue. This could be through regular check-ins, user forums, or even just being highly responsive to support requests. The insights you gain from these interactions are invaluable.

Set up regular sessions with your team to review how things are going. What's working well? Where are the pain points? What new opportunities have you uncovered? Use these insights to continually refine your product and your plans for its future.

Planning a digital product is both an art and a science. It requires creativity, flexibility, and a willingness to learn and adapt. Start with a solid plan, but hold it loosely. Get to know your users deeply. Create prototypes to test your ideas. Keep your initial product focused but build in ways to learn. And above all, stay curious and open to change.

Remember, every successful product you admire started as an idea, went through countless iterations, and continues to evolve. Your product's journey is just beginning. Embrace the process, learn from every step, and enjoy the ride. Who knows? Your digital product might just be the next big thing that changes the world.

Bringing a new product to life is an exciting journey, but it can be overwhelming without proper planning.

Planning Your Digital Product

Artificial Intelligence (AI) coding assistants promise to revolutionise the way we write software, claiming to save time, reduce errors, and even inspire new approaches. With these claims, it's no wonder many developers, myself included, have given them a try. I’ve spent significant time integrating AI coding tools into my workflow, both on local machines and through cloud-based services. However, despite the initial excitement, I ultimately decided to step away from these tools.

This decision wasn't taken lightly. I want to share my experience, the challenges I encountered, and why, in the end, the drawbacks outweighed the benefits.

One of the first hurdles I encountered was the performance of local AI coding tools. Many of these tools rely on the processing power of your local machine to generate code suggestions. Unfortunately, unless you have a high-end computer with top-of-the-line specifications, these tools can be painfully slow. Even on a decent machine, the lag between typing a piece of code and getting a suggestion from the AI was noticeable.

This lag isn’t just a minor annoyance; it breaks the flow of coding. Coding, especially when you’re deep into solving a complex problem, requires focus. Any interruption, like waiting for a tool to catch up, disrupts that focus. The time spent waiting for a suggestion or a code completion to appear was often more than the time I would have taken to write the code myself.

To overcome the performance issue, I turned to cloud-based AI coding assistants. These tools are faster because they leverage powerful servers to process and deliver suggestions almost instantly. The difference in speed was remarkable, and at first, I thought this might be the solution I was looking for. However, this approach introduced a new set of problems.

My primary issue with cloud-based AI coding assistants was their integration with my Integrated Development Environment (IDE). IDEs like Visual Studio, IntelliJ, and others have built-in features like Intellisense that provide smart code completions. These features are designed to understand your project, offering suggestions based on your existing codebase and the context of what you’re writing.

The problem arises when the AI coding assistant tries to do the same thing—often at the same time. The AI would make suggestions that clashed with the IDE’s suggestions. The result? A confusing mess of code completions, and more often than I’d like to admit, I found myself accidentally accepting an AI-generated suggestion when I was trying to use the IDE’s built-in functionality.

This conflict not only slowed me down but also introduced errors. For example, the AI might suggest a slightly different method call or variable name than what I intended, leading to bugs that were frustrating to track down. These interruptions were counterproductive, and the time I was supposed to be saving was instead spent resolving these conflicts.

Another major issue with AI coding assistants is that they rely on models trained on a snapshot of data. The most advanced models today are based on GPT-3.5, which was trained on data available up until the end of 2021. That might not seem like a big deal, but in the fast-moving world of software development, it’s a significant limitation.

Programming languages, frameworks, and libraries evolve rapidly. New versions with important changes are released regularly. These changes can include new syntax, new features, or even entirely new ways of doing things. When an AI assistant is based on outdated data, it can’t keep up with these changes. This means that the suggestions it provides might be based on practices that are no longer relevant or even incorrect.

For example, if you’re using a library that introduced a new function or changed the way something works after 2021, the AI might not know about it. It could suggest outdated methods or even completely wrong approaches. Relying on these suggestions could lead to code that is not just inefficient but potentially insecure or unstable.

As I used AI coding tools more, I noticed a worrying trend. I was becoming more dependent on them for generating code, especially for complex algorithms or functions that I would typically spend more time writing. At first, this seemed like a time-saver. However, I realised that I was starting to trust the AI-generated code without fully understanding it.

This is dangerous. While the AI can generate code that works in many cases, it doesn’t replace the need for a knowledgeable developer to review, understand, and verify that code. Trusting AI-generated code without this critical review can lead to subtle bugs, security vulnerabilities, or other issues that might not be immediately apparent.

Moreover, by relying on the AI, I found myself reading the code less. Instead of deeply understanding the logic and structure, I was just accepting it because it “seemed to work.” This goes against the very principles of good software development, where understanding the code you write is paramount. It’s not just about making something that works; it’s about creating something robust, maintainable, and secure.

One area where AI tools, particularly chat-based assistants, can be helpful is in speeding up code writing when given clear, specific prompts. However, I found that creating these prompts took more time than anticipated. The AI requires precise instructions to generate useful code, and crafting these instructions is an art in itself.

I often spent more time engineering the perfect prompt than I would have spent writing the code manually. This defeated the purpose of using the AI in the first place. The more complex the task, the more nuanced the prompt needed to be, which turned into a time-consuming process.

Additionally, even with well-crafted prompts, the AI sometimes generated code that wasn’t quite right. This required further tweaking and adjustment, which added even more time to the process. In the end, I found that the time saved by the AI-generating code was lost in the time spent crafting prompts and fixing the AI’s output.

The Future of AI in Coding: A Cautious Approach

AI coding assistants have great potential, but they are not without their flaws. For now, they still require a knowledgeable developer to guide them, correct their mistakes, and ensure that the generated code is up to standard. The limitations of outdated models, the risk of over-reliance, and the conflicts with existing tools make them more of a hindrance than a help in many cases.

This doesn’t mean AI has no place in software development. It can be a valuable tool, particularly for automating repetitive tasks or for generating code snippets that you can then refine and improve. However, I believe it’s crucial to use these tools with a healthy dose of caution and to avoid becoming too dependent on them.

For now, I’ve chosen to step back from AI coding assistants. They’re not quite ready to replace the expertise and intuition of a seasoned developer. But I’ll keep an eye on how they evolve. With further development, they may well become an essential part of the coding toolkit. For the time being, though, I’m sticking with my tried-and-true methods—after all, they’ve served me well for over 25 years.

Artificial Intelligence (AI) coding assistants promise to revolutionise the way we write software. Here's why I stopped using them.

Artificial Intelligence (AI) coding assistants promise to revolutionise the way we write software, claiming to save time, reduce errors, and even inspire new approaches. Here's why I stopped using them.

Why I Stopped Using an AI Coding Assistant

After conversations with some helpful developers on the #blazor channel of the DotNetEvolution Discord server, I have given Blazor a bit more of my time. I've left the original post below, but here are my amended thoughts after more perseverance and reflection, and a bit of a "lightbulb moment".

I still feel that the documentation is lacking. The onboarding experience for new developers is very far away from what I have come to expect of front-end frameworks, though it is very typical of .NET documentation. It tries to remain impartial and unopinionated but in doing so becomes disjointed and difficult for developers new to Blazor to use for their learning.

After a lot of discussion, my recent experiences in the Blazor support channels has been much improved. There appears to be a small core of people who are trying their best to help.

Tailwind support is still lacking. Using the Tailwind CLI directly, or using NPM and a node package to install and use Tailwind CSS seems to be the best approach, though this does take away somewhat from the "pure .NET" experience.

Additionally, I've found that, at least in the early days of using Blazor, it is easier to install and use a UI library such as MudBlazor than try to build everything yourself. While packages like this somewhat bridge the ecosystem gaps I see between Blazor and other front-end frameworks, and provide complex components that you can just drop in and use, they come with their own drawbacks.

For me, the main drawback of using these UI packages is that they are mostly using Material UI or some other internal design system by default and in a lot of cases you can't easily override their styling with Tailwind. It is possible to pass in other CSS classes with some of these libraries and components, but the results can be unpredictable.

This makes it a choice between using the library to save time developing your own complex components or using Tailwind for ease of styling.

In the original article below I talk about things that I found to be huge blockers. The number one thing I was thinking about when I wrote that was authentication. Specifically, handling OIDC authentication in Blazor with the new "InteractiveAuto" rendering and still being able to make authenticated requests to my separate API that is also authenticated via OIDC.

This seems to be a subject that is largely ignored or glossed over in courses, tutorials and documentation. I think most existing Blazor developers see it as "obvious" but for me, it was anything but.

This was the "lightbulb moment" I mentioned earlier. You don't need the access token in the Blazor Client project.

Using a package called Microsoft.Extensions.ServiceDiscovery.Yarp you can configure a "Catch All" route in the Blazor Server application that will act as a reverse proxy for your API. For me, it looked like this:

app.MapForwarder("/api/{**catch-all}", apiBaseUrl, builder =>
{
    builder.AddXForwardedFor();
    builder.AddRequestTransform(async ctx =>
    {
        var originalPath = ctx.HttpContext.Request.Path.Value;
        
        if (originalPath!.StartsWith("/api"))
        {
            var newPath = originalPath["/api/".Length..]; // Removes "/api"
            ctx.ProxyRequest.RequestUri = new Uri($"{apiBaseUrl}{newPath}");
        }
        
        var accessToken = await ctx.HttpContext.GetTokenAsync("access_token");
        if (!string.IsNullOrEmpty(accessToken))
            ctx.ProxyRequest.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    });
});

This will add the X-Forwarded-For header to the request to ensure the API sees the end user's real IP and attaches the Authorization header and access token to the request automatically if the user is logged in.

In this scenario, you handle the authentication only on the server. A copy of the important claims in the ClaimsPrincipal can be passed to the client part of the application using Persistent Component State as shown in this example app. The server maintains the authentication state using a cookie which is passed up on any request from the Client to the Server with Blazor.

Once you grasp how this works, it's like magic!

To understand this more fully, look up the "BFF Pattern" or "Back-end for front-end pattern".

Overall, I still think that Blazor is harder to learn than other front-end frameworks. However, I would amend my TL;DR; as follows:

If you already work with JavaScript-based front-end frameworks, you probably don't need Blazor. But you might want to learn it to gain access to some of its cross-platform and native app possibilities and to expand your resumé.

If you're a .NET developer looking to build front-end applications, give it a try. I'd still suggest learning a JavaScript framework too, so you have options and understand some of the finer points of how browsers work, but Blazor, once you "get it", allows you to build your entire application in a single tech stack. 

Personally, I still have a great belief in using the best tool for the job. Blazor has become another tool in my belt and I'm glad I stuck with it this time around. I look forward to seeing what the Blazor team at Microsoft do with it next.

If I could only make one suggestion to Microsoft about Blazor, it would be this: Invest more in the community and ecosystem. More "end to end" tutorials to help fill in the gaps in the documentation, more "out of the box" components to help build apps faster and to act as examples, and more helpful people in the various community channels with a remit of helping new developers trying to learn Blazor and to get over the hurdles that we face. Take a leaf out of David Fowler's book from the Aspire project!

Progress is impossible without change, and those who cannot change their minds cannot change anything.

I'm a .NET developer and have been for over 15 years. Before that, I worked mostly in PHP.

I say this, not to boast, but to give you an idea of what my biases might be. I've worked with .NET for a long time and have built many real-world production applications with it.

About 3 years ago I started learning how to use NextJS because I wanted to build API-first solutions and put nice, reactive front-end UIs on my apps. I've enjoyed using NextJS. I found the learning curve to be relatively shallow and the developer experience to be better than any other framework I've used.

However, Microsoft also has a front-end framework called Blazor that is supposed to be able to do all the same things as React, NextJS, Vue, etc. but using C# and .NET instead of Javascript.

If you already know a JavaScript framework well enough to build your apps, stick with it and don't bother with Blazor.

If you're a .NET developer looking to build front ends, maybe give it a try, but I suspect learning a JavaScript framework would be more time-efficient and productive in the long term (and is also a good thing on your resumé).

Blazor is a web framework developed by Microsoft that allows developers to build interactive web applications using C# and .NET instead of JavaScript. 

Blazor claims to enable the creation of client-side web applications with .NET, providing a rich, modern web development experience that allows existing .NET developers to leverage their existing skills and knowledge to build reactive front-end applications. 

Sounds perfect for me, right? That's what I thought too, so I dove into creating a Blazor front-end for my new API in .NET 8. 

The documentation is terrible.
Throughout this project, I constantly found myself digging through Microsoft's documentation and examples only to discover that the examples don't work, are incomplete, or are specifically for Azure and won't work for non-Azure things.

The online support is almost non-existent
I posted my questions and issues to a number of places, including the "official" Blazor channel on the DotNetEvolution Discord server. I posted code examples, and detailed descriptions of what I was trying to do and the issues I was having. 

In most cases, I got no responses at all. In some of the worst cases, I was ridiculed and belittled by people for not already knowing how to use Blazor. In the end, I was able to get some help from one specific Microsoft employee on the Discord server, but it took me to post a rant before that happened.

This is a trend I've noticed in the Blazor community - Only the people who whine and complain and cross-post their questions across multiple channels, often spamming them multiple times, get any attention or help. The people who follow the rules and post well-thought-out questions with code examples largely just get ignored.

No Tailwind CSS
I use Tailwind in most projects because I find it easy. It builds really small CSS bundles that don't bloat over time and are just a pleasure to use for any component-based framework.

Getting Tailwind working in Blazor is possible, but it's painful and you better be prepared to edit your *.csproj files and add new custom build targets. If you want the Tailwind "watch" functionality, be prepared to write a custom script and use their CLI.

Simple things become huge blockers
This is partly due to the terrible documentation and support, but as I was building my project I found that things that I take for granted in other frameworks just don't work in Blazor out of the box.

Environment Variables for example - you can't access them in the Blazor WASM client without doing a bunch of custom work to somehow pass them to it from the server.

By contrast, in NextJS you just prefix your environment variables with "NEXT_PUBLIC_" and boom - you can access them in your client components.

Another example is authentication. The documentation for OIDC authentication, and the examples they provide, just don't work in the WASM client. 

I want to like Blazor. I really do. It has so much potential and would mean that I could build entire apps without leaving .NET. It would even simplify hiring for new developers since I'd be able to just focus on .NET.

In reality though, I just find myself hitting one roadblock after another and getting more and more frustrated. 

In the time it took me to solve the issues with environment variables alone, I could have had my application halfway complete in NextJS.

Unfortunately, I can't see things getting better, nor can I see Blazor ever really competing with any of the major JavaScript frameworks. 

While Microsoft continues to add new features and improve Blazor, the fundamental problem with it is the onboarding experience for new developers and the overall developer experience stemming from fragmented and incorrect documentation, paywalled tutorials and elitist community members who are unwilling to help.

My thoughts on Blazor as a front-end framework, its learning curve and its community.

An honest summary of my own experiences trying to learn Blazor

Is Blazor worth learning in 2024 - My Experiences

An honest summary of my own experiences trying to learn Blazor in July 2024.

Is Blazor worth learning? My Experiences...

Over my career, I've seen so many website rebuild projects and the one thing that is always underestimated is the amount of work involved in migrating your content from the old site to the new one.

Even if you're sticking with the same CMS, content migration will still be needed in most cases and it can be a tedious and time-consuming job to do manually.

Set aside some budget for a content audit. This should produce a report about which content can be migrated using some form of automated process, which content you might not want to migrate at all and which content you will need to migrate manually.

For most sites the vast majority of content will be blogs or articles and, unless you've used some kind of page-builder for these, your developers can likely write a script to migrate these automatically. There may be other types of content in your site that can be migrated automatically too.

Automatic migration doesn't necessarily mean cheaper. There's a lot to consider when writing automated migration tools such as:

Migrating inline/embedded media files like images and ensuring that the content is updated to reflect the new media location.

Updating hyperlinks to internal content to wherever the new location of that content is (and flagging up broken links).

For the content that can't be migrated automatically, you will need to figure out how much time it will take you to copy and paste the content from the old CMS to the new one, including reuploading any images or other assets, re-linking inline hyperlinks and creating redirects. This can be a long and tedious job on large sites so ensure that you have enough people around to help you do this.

Planning and preparation are key here. Don't let content migration derail your whole project by not investing enough time and money into it upfront.

If your content and URL structure is changing (which it likely is if you're rebuilding your site) then you need to have a plan in place to create redirects from the old to the new.

I have seen businesses literally disappear overnight by not doing this. 

If you don't redirect your pages when the new site launches then you will lose ranking in search engines. If enough of your pages suddenly start returning "404" errors then Google may de-index your site entirely.

It's a really simple task to have your SEO scan your old site and work with your developers to produce a redirect map that can be implemented into your new site from day 1. This will save you a massive amount of pain after launch.

You are going to be changing the way that your users interact with your website. The way they browse and find your content. Hopefully, that change is for the better but you can increase your chances of success by investing a little time and budget in the early stages of the design process to carry out some user testing with the new designs.

This will give you valuable feedback at a time in the projects lifecycle where you can still make changes without incurring a lot of extra costs. Spending some time and money at this stage can actually reduce the overall cost of the project by ensuring that you won't launch something your users hate.

I wrote this article because these three things are the things I see almost everyone gets wrong when planning website rebuilds. They are things that either get left until the end of the project or are forgotten entirely and then rushed in at the end of the project causing delays and additional costs.

Website projects will usually have a finite budget, but sometimes you need to spend a little more time and money upfront to make greater savings in the long term. Putting some of your budget into these things can save you more by the time your new site launches.

Rebuilding a website can feel a lot like moving house, with all the stress that comes with it. In this article, I'm going to look at a few ways you can reduce the stress involved.

Website rebuilds are stressful enough. Here are 3 simple things to save you stress on your next website rebuild.

3 simple things to save you stress on your website rebuild

In my time working in an agency, I've seen a lot of projects and a lot of discussion around how best to plan and run various projects in the agency environment. Distinction's 2020 brand repositioning to the strategy agency that's all about the action led to some interesting discussions and changes in the way we think about and plan for projects.

It's been clear for over two decades now that the old way of planning and managing projects, known as the Waterfall methodology, just doesn't cut it in today's world of high-speed change. The COVID-19 pandemic and the changes that came with it (and continue to come) show us, beyond a doubt, that even the best-laid plans are meaningless in the face of a world that changes so rapidly from one day to the next.

So why do agencies continue to present rigid, up-front plans to clients? Why do clients continue to insist on having a contracted scope and budget for their project up-front? 

In short, businesses want things to be done in a certain amount of time and they don't want to spend more than a certain amount of money to do it.

This means that agency sales teams feel they need to promise clients exactly what they are asking for in order to win the pitch.

This way of thinking from clients to sales teams leads many agencies into adopting a waterfall approach from the start of their sales process and this can make it very difficult to transition into a more agile approach for project delivery since all of the estimates are already seen as "fixed" by the client. What do you do as a project manager or developer when you're asked to produce more detailed estimates and they end up being more than the estimates that sales used to win the project? It puts project managers in a difficult position and invariably ends up in some very uncomfortable conversations with both the agency leadership and the client.

Firstly we need to move the conversation from features and more towards goals. This is a subtle but important distinction to make. A feature is "how it's done" whereas a goal is "the outcome we want". Once the client is talking about their goals the "how we get there" is much more flexible.

We can then begin to refine the client's high-level goals into more actionable requirements. These then form the high-level epics of the project and the next step is to get the people that will most likely be doing the work to give these high-level epics some estimates - but not time estimates.

A good way to estimate these high-level epics, and my personally preferred method, is to use "Story Points" based on the Fibonacci sequence. Get the delivery people in a room (real or virtual) and play a game called "planning poker".

Timebox each epic - 5 minutes for example - and allow the group to discuss it and ask questions to the people that worked with the client to define it. At the end of the 5 minutes, each person that will be involved in the delivery makes a secret "bid" of story points from the sequence below.

In the Fibonacci sequence, each number is the sum of the two preceding ones, starting from 0 and 1. The sequence "1, 2, 3, 5, 8, 13, 21" is commonly used for planning and estimation in software development projects.

Everyone reveals their bid at the same time and if they are all the same that is the estimate for the epic. If there are differences you just discuss the outliers and come to a consensus quickly. Any discussion at this point should also be timeboxed - the idea is to estimate quickly and move on.

These estimates will give you an idea of the complexity of each epic and while these points don't translate directly to time at this point, they are useful in determining where the majority of time will likely be spent.

Once you've estimated all of the epics look for any that have been awarded the highest value allowed in your sequence. These estimates typically come from a lack of knowledge or something that is too broad in scope. Each of the epics at the top end of the estimate range should be discussed separately to determine why the estimates are so high with a view to either getting more information from the client or breaking them down into more manageable pieces. Eventually, you should end up with a list of epics where each epic alone doesn't feel like a big daunting piece of work and you feel like you have all of the information you will need to produce it.

Now that you have a list of well-defined requirements and an idea of how much effort each will require to deliver each, it's time to go back to the client and talk about priorities.

I like using the "MoSCoW" system for this as it helps the clients to prioritise their requirements without getting bogged down in too much detail. Ask the client to mark each requirement as one of the following:

This process helps to define the intended scope of the project. Everything in the "Must", "Should" and "Could" categories should be considered as "in-scope" at the start of the project.

Items in the "Would like to have" category can be kept in the project backlog as "stretch goals" but it should be clear to all parties that those items will not be planned into the completed project or worked on unless everything else is complete.

Prioritising items in this way helps us to understand the order in which features or stories should be completed. Ideally all of the "Must have" items would be completed before any "Should have" items are started, and so on.

No project ever runs to completion without something changing. Whether it's a new requirement, a change in the client's business priorities, delays from third parties or just that one of the requirements ends up being more complicated than expected.

In these cases, the conversation with the client is much easier to start because they've been thinking about priorities all the way through so far. When that new priority comes in or the big "must-have" feature takes longer than expected we can talk to the client about either extending the budget/timeline or dropping one or more of the lower priority items from the project to take account of the change in circumstances.

Since, in an agile project, you'll be talking to the client much more frequently than you would in the old waterfall method, they can be made aware of these things sooner avoiding any surprises towards the end of the project.

It's a fact of business life that clients will want to have some assurances of both when they will get what they're paying for and how much it's going to cost them. In established agile teams it's relatively easy to estimate a timeline for a project based on the team's velocity (number of points completed over time) on previous projects. This is much harder to do in an agency where you may not be working with the same team members for every project.

It's also a fact of software development that there will always be surprises in any project. There's no way that we can know all of the ins and outs of a clients business processes at the start of a project. There will always be things that only come out once we start actually building the project and, most of the time, the project can cope with them but there are those occasions where a feature turns out to be far more complicated than originally described.

The answer is to change the question. Rather than promising fixed scope and a fixed budget to clients, just pick one. You know your client best. Which is more important to them; the budget or the scope?

Make sure that they understand that you will do as much as can be done well with the time/budget available. Things lower down their priority list may need to be dropped from the scope to achieve that. Most clients will be fine with this in the early stages of discovery and development and, if it becomes an issue later, you have set expectations early and at that point, the client can choose to either drop a low-priority feature or add to the budget so that it can still be completed. In most cases they will drop the feature since getting the project to market will be more important.

It's better to get it to market and then improve on it than to never get it to market at all.

The other side of this is where the client must have all features to make their product viable. In these cases, they must be prepared to increase their budget to cover any surprises, or to be more flexible with the scope to allow lesser implementations of their features in version 1. 

Overall, communication with the client is key.

In my experience any project where scope and budget are fixed is doomed from the start. By having both set in stone you only encourage corner cutting and the product you end up with will not be well built and will be difficult to change and maintain in the future.

Do yourself and your business a favour - work with this process and allow lower priority items to drop out of scope if needed. You can always add them in later once your project is live and bringing you some return on your investment.

In my time working in an agency, I've seen a lot of projects and a lot of discussion around how best to plan and run various projects in the agency environment.

Diving into my experiences of agile software development in an agency environment and how agile can be used in an agency effectively.

Agile in an agency

In my profession, I often come across businesses looking to move to new hosting or host a new website. In many cases, I get the chance to talk to them about the different options and help them choose the best hosting for their purposes.

Sometimes though, companies already have their own infrastructure, be it co-location, dedicated servers or some sort of virtualised environment such as Azure VMs, VPS etc. and they are reluctant to even discuss other options after having sunk so much money into staffing, training and the hosting its self.

The trouble is that all of these types of hosting have one thing in common –  they cost you a lot more than you think they do and continue costing you over time. You have to constantly manage:

The operating system configuration and updates (which can also cause you issues)

“Bare metal” backups to restore if something goes wrong

Drivers and their updates (which can cause you issues too)

The web server (IIS, Apache, Nginx, etc) and its configuration and updates

And that’s all before you even get to managing your website(s)!

Sometimes these companies will employ people or teams of people whose only job is to maintain all of this architecture.

Worse still, I’ve had to deal with issues that arise from internal IT and infrastructure teams applying updates to OS or drivers that have then broken integrations with 3rd party APIs or just outright broken the client’s website altogether. These infrastructure teams often have no idea what the websites hosted on the infrastructure are using or communicating with and will often just apply “recommended” updates without adequate testing.

Most companies could achieve suitable (or better) hosting for their website(s) and databases using cloud alternatives and rid themselves of the overhead and headache of maintaining infrastructure themselves.  Better yet, cloud hosting is held to a high standard when it comes to the types of changes that can be made and you will usually be notified of any upcoming major changes with enough time to update your websites or tweak the settings as needed.

For .Net, PHP or NodeJS based hosting you could use a container-based service such as Azure App Services.

The difference between an App Service and a VM? With an App Service, You don’t have to manage the server at all! You can just concentrate on your website and leave the hardware, system updates, etc. to the cloud provider.

In addition, if you need additional power for your website to cover busy periods it is much easier to scale the hosting up and have the app service deploy additional load-balanced versions of your site than it is to provision new servers or VMs.

Backups are a pain to manage with most database systems. The best I’ve ever seen a company set up their database backups is to have nightly full backups. That’s a potential 24 hours of lost data if anything goes wrong. With cloud databases, it can be like having a full backup every minute.

Whether you need Microsoft SQL Server or MySQL, the cloud has you covered there too.

For MSSQL database my go-to service is Azure SQL databases. They provide you with a to-the-minute point in time backups and restoration system all managed by Microsoft.  If you ever need to restore from a backup you just enter the date and time you want to restore to in the Azure Portal and let it do its thing.

For MySQL, a similar service exists called Azure Database for MySQL server. These have a very similar feature set.

If you’re looking to host a WordPress site, using a specialist WordPress host with a containerised environment such as Pantheon or Flywheel can be incredibly liberating. You don’t have to worry about webservers or databases yourself – you can just focus on your website.

Gatsby, Gridsome and other JAMStack built sites

If you’re using JAMStack static site generators then you likely already have a good grasp of the benefits of a fast site. Specialist hosting such as Netlify or Vercel can simplify both your hosting and your deployment processes.

Even if you want to go the route of setting up your own hosting, a simple CI/CD pipeline, some Azure Blob Storage and a CDN are still much simpler than hosting an entire server.

Long story short, stop wasting time, money and people-power on maintaining servers. Instead, leave that to the specialists and focus on making your website deliver a better experience for your customers.

Cloud hosting and container based hosting architecture has come a long way recently and can be a very cost efficient way to host websites, but many businesses continue to spend a lot more on in-house or dedicated hosting systems and architecture.

Stop making hosting hard for yourself!

In the ever-changing landscape of devices and web browsers that your visitors will be using to access your website, one thing remains constant: A fast website is better than a slow one.

In 2020, over 50% of internet traffic was from mobile devices.

Google has taken note of this for some time now in their Google Page Speed  Insights tool, and in the Lighthouse software that powers it. They routinely test your websites speed by using simulated mid-range mobile devices and by recording real-world speed data from your visitors’  devices.

It’s no secret that Google has been using page speed as a  ranking indicator for some time. Indeed, many clients I talk to cite page speed as one of their main concerns.

Stop building your pages on every request!

In  a traditional website, whether it’s powered by a CMS such as WordPress,  or some custom-built solution, every visitor to your site follows this  process to view a web page:

The visitor enters your web address into their browser or clicks a link.

Their browser makes a request to your server for the page.

Your server runs that request through some programming code that makes multiple requests to a database to retrieve raw content and then runs more code to inject that content into some sort of template to produce an HTML document.

Your server then sends that HTML document back to the visitor’s browser.

Out of those 4 steps, #3 typically accounts for between 0.5 and 2 seconds of real-time that your visitor has to wait before their web browser even begins to display anything and every visitor is seeing this on every page load. This is called the “server processing time”, sometimes called the TTFB (Time to first byte).

What if I told you that you could eliminate that time from your visitors’ experience altogether?

Well,  you can, and here’s how; You need to use something called a Static Site  Generator. These are sometimes referred to as JAMStack or SSGs.

Two of the most popular SSGs out there at the moment are Gatsby and NextJS.  Both provide excellent developer experiences based on the React  JavaScript framework but, most importantly, both have thriving communities of developers building plugins and addons to help other developers create stunning, fast websites quickly.

A static site generator is only one-third of the puzzle though. While a static site  generator will do the work of building your website as a package of  static files, you still need two other things:

Some way of editing your content in a place that the SSG can retrieve it.

Somewhere to host the static files that the SSG builds.

Technically,  you can host a statically built site on any hosting you like. You can even host it in Azure blob storage or an AWS S3 bucket.

You could do those things. You would need to create and manage your own build pipelines using something like CircleCI or Azure Pipelines, but it is possible.

Alternatively, you could host the statically generated site with a service that is designed to manage the build process and hosting from start to finish.

Netlify is one of the most established hosts for JAMStack sites. In fact,  Netlify also supports most SSGs, including Gatsby and NextJS, and make it very easy to get a site deployed quickly.

Gatsby has its own offering for hosting which, when hosting GatsbyJS sites is comparable to Netlify.

For next the best choice in my opinion is Vercel as it gives you other features and options with NextJS that are not available on Netlify or any other static site hosting that I know of.

With the hosting sorted, it just leaves you needing a place to write and edit your content.

Blog articles