Solutioning, the gentle art of not wasting everyone’s time.
The Secret Sauce to Agile Development Part 4
30 years of experience getting it right distilled into my new blog!
Greetings and welcome to Blog Four in the Secret Sauce of Agile Development, which delves into the incredible world of Solutioning! This is one area that is absolutely dripping with AI goodness, so keep an eye out for the ‘where can AI make this stuff better’ sections cunningly hidden throughout the blog in plain sight.
Oi grandad! What on earth is that? What’s it got to do with writing code, and why is it incredible?
Well, Jimmy, solution engineers play a key part in the development process. These guys analyse the customer’s requirements and come up with a software solution that won’t actually explode on contact with the internet. Could be anything from a mobile app to an in-car infotainment system, government smart energy monitors or even health and safety systems for nuclear power stations (been there, done all those, still wearing the t-shirts and matching lanyards).
Indeed, the top and most successful solutioneers work directly with the biggest companies in the world, jet-setting around the place, sipping champers in pent-house board meetings, inhaling Michelin-starred burgers and getting paid a damned-sight more than 2 tins of beans a week!
Talking smoother than Templeton Peck, Frank solves all the customers' problems whilst raking in more dough than Arthur Daley on steroids.
Good solutions architects can not only talk to the customers but also understand the technical details behind a working solution. Fluent in Kanban, they collaborate with the delivery team to agree on a viable plan before handing it off for implementation, testing and release.
Solutioning is super important as even in a small project like our Blog’s real-world example, we still need to demonstrate we can deliver what the customer has asked for, given the tech stack, budget, and team available. Our stakeholders will want convincing that our crack team of experts can actually build what craziness they’ve asked for so they’ll part with their hard-earned cash. These smaller businesses can be tighter than a duck’s derriere, and rightly so; they can’t afford to chuck money out on some project that’s going to make a loss or worse, keeps hoovering up cash every time a delivery date slips.
Likewise, our team will need comforted and reassured that the proposed solution is actually doable and not some hairbrained scheme that's totally impossible to implement. Besides, before we dive into the first sprint, we need to know what we’re actually doing—not just blindly tapping keys and hoping for the best.
You told them we could do what???? Frank gauges the reaction of the dev team after he’s already sold the solution to the customer without consulting them first.
To summarize all that waffle:
Solutioning is coming up with an idea to deliver what the customer is actually looking for.
I said deliver, not build, because it might not involve writing any software at all. Maybe we can generate something prebuilt using AI, or grab an off-the-shelf package that ticks all the boxes—charging a healthy cut, naturally. And I said solution because it might not even be software. Our job is to solve the problem, not just sling code at it and hope it sticks.
🧻INANE RAMBLING, Card before the Horse
One of my mates, an expert software developer and solutions architect, helped a poor client struggling to keep tabs on his customers. No CRM, no spreadsheets, no leads, hell, he couldn’t even find their phone numbers. He asked if my mate could come round and ‘build him some software to sort the problem out as a favour’ (some people have no idea). “Great, have you any experience using a computer?” 'No, none whatsoever'.
So on the way round, he calls by the stationers and picks up one of those old-school card organizers, with a separate card for each contact to write helpful details on them. They come in a nice box with different colour tabs to help you sort the cards. It only cost a couple of quid and the client has never looked back.
Okay, that’s maybe an extreme example—but it makes the point: sometimes the best solution isn’t software. It’s thinking outside the box before you waste time and money on something you can’t deliver.
So what does this look like in practice when the stakes are higher than a box of index cards? Let’s take a jeff at our example project:
🌍REAL WORLD EXAMPLE, The Coin Shop Conundrum: Building Big on a Budget of Beans
Building Charlie Bluster’s online coin shop should be straightforward as t-internet is loppy with these sorts of applications and websites. It should also be simple to inject new code into Charlie’s other products and games to create achievements that can earn coins. Payment platforms like Stripe are also readily available, all of which are reliable, performant and most importantly, come fully security tested.
The big gotchas aren’t in the implementation; it’s the constraints that our annoying client has put on the project, most especially the fact that there is no extra dosh to operate the final product. We need to choose a solution that is free to run or at least will generate suitable profits to pay for the infrastructure. This means we can’t pick some expensive relational database solution like Microsoft SQL Server running on Azure; likewise, we must limit things like serverless code that charges per API call, as our bill could rack up faster than Usain Bolt running for the bus.
🤖Where can AI make this stuff better?
Most teams out there will be faced with something a bit tougher than our Coin Shop. If it’s too early in the morning or there is only decaf available, your dev team might struggle to think of a viable solution from the top of their heads. If so, dropping a prompt in your favourite AI chat assistant will return some possibilities.
- I need to write a coinshop with an html front end. What technologies can I use for the back end that will be free with zero or low running costs.
Microsoft Copilot must get it's coffee early as it aced this first question.
Top of its list is Google Firebase. We can easily dig deeper and have Copilot come back with more information. I’ll let you, dear reader, do that little exercise on your own.
Suffice it to say, Firebase is the bees' knees! Free hosting, free APIs, free data, and a whole set of UI controls and libraries to manage stuff like logins. At least it's free until we reach a certain set of benchmarks, after which we have to fork out per megabyte of storage or for numbers of API calls.
This works well with our requirements as if it gets to that point, it should mean that our customer will be earning a lot of money selling products and will be easily able to afford the runtime costs.
But is it going to be difficult to write the code in it? Some of our team have never used it before! Let’s ask Microsoft Copilot. Here’s a screenshot of my prompt:
Hardly pausing for breath Copilot brings home the bacon once again.
I’m not going to bore you all by pasting in its lengthy reply, but let’s just say that Copilot is pretty confident that building this solution should be easy peasy.
🤖Where can AI make this stuff even better?
Just for giggles, let's ask it to write the code ....
Firing on all cylinders, Copilot begs us to ask the question whether we need a dev team at all?
I’m also not going to paste in the reams of code that Copilot has cheerfully spat out onto my screen, but it’s pretty much generated the entire application in less time than it took me to scratch!
Hang on, what?? We just wanted to know if the code would be hard, but what the AI has GONE AND WRITTEN THE WHOLE APPLICATION FOR US???? And even better, it’s done that in like ten seconds flat!!!!
I mean, come on, surely that’s a load of tosh. You're just a mad old fogey and this is some sort of dumb joke to get people to read your stupid blog? It’s not actually going to work? Is it??
Well, Frank, guess what? I went off, downloaded the code and dumped it into a test version of the customer’s website. Don’t believe me, well here’s a picture of it running:
Microsoft Copilot gets the job done faster than it takes me to stir my tea, Heavens to Mergatroid, it actually works too!
🚨 Don’t Ship It Yet, Frank
WOW TIGER, put that phone down! I know what you’re about to do: you’re going to call the customer up and tell him his application is finished and he’ll get it by COB!
Ha ha ha ha! That is the fastest route to development hell that I’ve ever come across. Sure, we’ve got a piece of working code, but it doesn’t fulfil the requirements, it’s not tested, it’s running off Phil’s laptop, not really got a clue how to release it yet and a whole host of other problems.
We’d better go and talk to our dev team and see what they think about it. If you’ve been around agile software development for a while, there’s an expression you may have come across called ‘The Three Amigos’. The manager rounds up these Three Amigos, who are a developer, a tester and the product owner, to get their opinions on the proposed solution. Personally, I think this is a bit outdated and that the Three Amigos are missing both Dartagnian and Lancelot, (and probably Merlin too).
In fact, what we really need is at least one representative from each department or skill area involved in our project. This could include our data expert, our infrastructure engineer, the build and release guy, the non-functional tester and the marketing exec, amongst others. We need each of these people so we can understand if unforeseen problems in their particular area may crop up. For example, it might be easy to code the solution, but we’ll be scuppered if the testing turns out to be extremely time-consuming and expensive.
The lads, being a few turnips short of a stew and not having enough experts on the team, may need to call in the cavalry.
🤖Where can AI Make this stuff flippin’ awesome?
Maybe you don’t have all these people available, or perhaps you’re working on your own? Well never mind, Secret Sauce Blog to the Rescue! Here is a nice prompt to create AI personas for each role in our development team!
You are a cross-functional software development team with experts on coding, testing, test automation, security, performance, accessibility, database architecture, build and release and infrastructure. You have 20 years’ experience with a particular focus on web technologies. You are able to analyse proposed solutions and comment on them against each of the different expertise available.
What about that then?? Let’s see what our new panel of experts thinks about our Firebase solution. Just keep your eye on those ‘Watchout’ sections where trouble might be in store.
Copilot:
This is a fun concept with a rich blend of gamification, engagement incentives, and Firebase-driven architecture. Let's analyze it from each cross-functional angle:
💻 Coding & Architecture
- Strengths: The use of embedded JavaScript with an HTML front end keeps things simple and browser-friendly. Firebase's modular SDK suits REST APIs well.
- Watchouts: Without a framework (like Vue or React), state management may get tricky, especially with coin balances, review tracking, and API coordination. Consider modular JS structures or small-scale client-side state libraries.
🧪 Testing & Automation
- Strengths: Firebase Emulator Suite supports local testing of functions and Firestore.
- Watchouts: REST endpoints will benefit from automated unit and integration testing. Tools like Vitest (already on your radar) could pair with MSW (Mock Service Worker) for API mocking.
Security
- Strengths: Firebase Authentication gives you strong access control. Reviews and coin transactions can be scoped per user securely.
- Watchouts: Make sure review data isn’t forgeable—coins should only be awarded on valid, authenticated submissions. Protect against API abuse (rate limiting, verification checks).
⚡ Performance
- Strengths: Serverless functions scale effortlessly; Firestore handles moderate load well.
- Watchouts: Coin calculation logic may require batched writes or transactions—watch for performance dips during high activity. Consider caching coin balances client-side with validation fallback.
Accessibility
- Suggestions: Use semantic HTML tags and ARIA labels to make the shop and review interface accessible. Keyboard navigation is key in a gamified interface.
🗄️ Database Architecture
- Strengths: Firestore’s flexibility suits evolving schemas like reviews and transactions.
- Watchouts: Consider separating collections: users, products, reviews, transactions. Coins might be stored in a wallet subdocument or as a computed field—evaluate risks of drift and update timing.
Build & Release
- Strengths: Firebase Hosting will serve static HTML + JS easily.
- Watchouts: Without a bundler like Vite, scaling and optimizing JS for performance may be harder. Also, versioning for reviews and coin logic should be considered as your shop evolves.
🛠️ Infrastructure
- Strengths: Serverless deployment is a win for simplicity.
- Watchouts: Be sure to emulate functions locally, especially coin awarding logic and Auth flow. Redirects and CORS configuration will be essential for smooth front-end API communication.
Overall, you’ve got a compact but well-structured blueprint—and the coin-based economy is a great hook for retention and repeat visits. With your hands-on Firebase skills and JS troubleshooting experience, you’re in a strong position to pull this off. Want help modeling your Firestore schema or architecting your reward logic next?
🍟TAKEAWAY TODAY
Oh dear, looks like there may be one or two little gotchas in there, perhaps it might be wise to put that phone down, Frank and not tell the customer we’ve finished the job just yet, hell, we’ve not even tested that the thing is working.
The Takeaway Today is that this prototype is not the final solution. It’s to demonstrate that we can deliver what’s been requested, and it's effectively a throwaway. We’ve not spent much time on it, and it's hardly brimming over with quality, but we have learnt valuable lessons that can be taken forward as we build the actual solution.
🌶️HOT TIP, Mind Your Eyes
Hey, Mr Manager, just a quick word on the AI before you go off and fire your whole dev team.
Through my incredible writing skills and easy-to-read style, it might come across that the whole shebang was simpler than eating pie, but I’m afraid that wasn’t quite the case, so hence this little word of warning.
The AI-generated code, whilst extensive, needed to be reviewed and contained several bugs that I had to kick out.
To fix these, my initial reaction was to type a complaint into Copilot and ask the naughty AI to immediately correct itself! Unfortunately, the AI is non-deterministic (eh?) Sorry, Frank. I did promise not to use too many big words. It just means that each time we ask the same question, we’ll get a different result. And, as far as the code is concerned, this means it returns a slightly different version every time.
In particular, it enjoyed changing annoying details like the title of the web page, the layout of the controls on screen, but crucially, it also frequently changed the versions of the JavaScript libraries used.
Now, while many readers won’t be too fazed by that statement, Phil and a few other hardened code junkies out there are probably experiencing a dose of the shakes, forcing them to reach for the brandy. Suffice it to say that these sorts of changes can introduce nasty bugs that are very difficult to find, or worse, can cause the whole application to quickly stop working.
My hot tip is therefore to review any code that the AI generates, and in some cases, it's actually easier and better to fix problems yourself.
TUNE IN NEXT TIME
This all looks very peachy, we’ve nailed the requirements, scoped a viable solution, and even got some test code running – all in record time. Also, our crack team of experts reckon that with a bit of effort, we can test and deliver the project within the constraints specified by the customer.
Now it’s time to sit down with the client and replay the requirements to demonstrate our understanding and our ability to deliver what he wants.
What we’re asking for in this meeting is sign-off and permission to start the project. Mr Bluster is almost certainly going to want to know how much he’ll have to spend and when working software will be provided, and how much he’ll get back.
What we can tell him at this point is that we need a couple of billable days to plan the project in detail, and we’ll come back to him then with hard numbers.
That’s why Blog number 5 in this amazing series of life-changing articles is going to delve into Project Planning. Mark it in your calendar, tie a ribbon around something or do a handy reminder forehead tattoo, just don’t forget to tune in next time.
I’m afraid that’s it for blog 4, Sayonara dudes, and don’t forget to tune in again for more agile antics, and please, please share this on your socials as I’m sure there are plenty of other Franks out there who need a little enlightenment.
🧃Juicy Download
In the meantime, I’ve summarized the main points from this article in this handy download. Enter your name and email address and a nice PDF will wing its way directly to your inbox.
We'll also notify you when future editions are released and send their notes without having to sign up again, (and you can unsubscribe at any time).
Thank you for subscribing!
Have a great day!
Additional Image Credits