My great friend has just landed a new job as a software developer. While soaking up the sun, we took pleasure in discussing his new role over coffee outside one of the best coffee shops in Europe. His position comes with a high degree of responsibility: working for a well-known European brand, with a salary to match. Refreshingly, it does not involve any Scrum methodologies. In a tech world obsessed with ceremonies and rigid frameworks, this felt like a breath of fresh air. The role was reminiscent of my contracting days in London, back when people just got on with it and things actually got built. As I walked home, I mused over our conversation and felt compelled to write this article as a reminder that there is another way to work: fast, lean, and directly with the business. Before I dive in, let me give you some context: I wrote software for banks, law firms and financial consultancies for over 20 years. My strength was in rapid application development (RAD). There were no Scrum ceremonies and no layers of management between me and the business. No fluff, just pure Agile. And since I was a contractor, this meant that if I faltered, I was out. No passing Go. No collecting $200. This article is a primer on how I worked in these environments as a 'stealth consultant', and why that approach still matters.

Words to Live By

If you change it, you own it. Basically, you'll receive a lot of homework if you cock something up by changing something outside the requirements.

Keep it simple, stupid (KISS). No autoMappers :-) or CQRS unless absolutely necessary. If you feel the urge, call me and I’ll come to your place to give you a slap.

The devil is in the details. Stay on top of them. You'll save yourself from future issues.

Schoolboy errors. You’ll make them, but learn to avoid them. Fix them fast and hope no one notices.

To name a thing is to know a thing. A lot of software development comes down to naming things correctly and putting them in the right place. Learn the difference between a noun and a verb. Functions and methods include a verb (Get, Create etc.) in their name, whereas namespaces, classes, properties and variables do not.

As a side note: I’ve seen namespace paths include verbs like create, read, update, and delete. I would class this as a schoolboy error.

You are more than just a developer. Think of yourself as a project manager, business analyst, software developer and innovator with a touch of the Maverick.

Just never go too Maverick.

Let's Me Give You Some Strategies

What follows is what I’ve learnt while working within large multinationals.

Settling into a New Role

I always take a database/model-first approach for existing and new projects. Get the state model right, and the rest will sort itself out.

Get yourself a Visio licence to draw the model. The web version is too lightweight. The desktop version allows you to create custom templates and exposes its object model so you can hook it into your own C# apps. See www.delaneys.space/software/sketchbot as an example.

The model-first approach enables you to do a great deal of code generation. Handy for delivering high-quality work at pace.

Build an SQL script to create a copy of the production database, but with key data anonymised. You may want to limit it up to a 1,000 rows per table, though this can break 1:M relationships.

You’ll need access to the PROD environment to work fast, but as some wise sage once said, 'With great power comes great responsibility' – Uncle Ben..

On Going Technical Improvements

Remember you change it, you own it.

Make sure the DB schemas are the same for DEV, TEST, and PROD. The last thing you want is a trigger on PROD that’s missing in DEV, or a non-clustered index on DEV that’s not on PROD.

Refactor the DB(s) if any of it is BS. BUT this can be very expensive (including potentially costing you your job), so be very, very careful with this one. You might not have the stomach for it early in your project engagement, and I wouldn’t blame you.

Refactor the solution(s) if any of it is BS. This can also be expensive. See above.

Make the release process for a solution as easy as possible. Ideally, a double click. Usually, this is achieved by having script written in your favourite scripting language. There is no need to set up a CI/CD pipeline unless you’re planning on running a plantation model of software developers, with layers of admin staff to manage them.

Change and Stakeholder Management

1. Use a Spreadsheet as your change log. It gives you full control over the fields, and allows you to create reports quickly.

   Record how long it takes to carry out each change; this includes any meetings greater than 15 minutes, documentation, coding and your own testing. I wrote an app for that. You can download the source code from GitHub.

   Changes will fall into 1 of 6 buckets:

   	Easy	Hard
   High	😎😎😎	💩💩💩
   Medium	😎😎	💩💩
   Low	😎	🤡

   😎😎😎 - This could mean a calculation or rounding error in a profit and loss report. Many of these changes can be fixed in a day for you to earn hero status.

   🤡 - If the CSS is on the fritz, causing a minor misalignment issue, it gets a clown face because one can spend days trying to fix it for a small gain. Sooner or later, it will start to grind your gears and eventually, you’ll bend spacetime to fix it.

2. Write concise change request (CR) documents in MS Word. Use the tone 'The solution WILL do this when…'. Use stakeholder business language and include diagrams and tables where appropriate.

   This document must be easily understood, even by the mousey-est of mousey graduates in their early 20s. Build a bridge to the business. Don’t expect the business to come to you.

3. Use multi-layer numbering for each paragraph. Doing so mitigates the small frustration of directing a reader to a paragraph.

4. As you write, you may uncover 'open issues' that need to be addressed at a future discussion. Capture them in red borders so they don’t get lost.

   Open Issue

   This is an example of an open issue.

   You can do something similar when you need to record a technical note, but this time use a blue border.

   Technical Note

   This is an example of a technical note. Remember, the CR is your document too. Stakeholders can ignore these, but they seem to appreciate their presence.
5. Do not use LLMs to enhance your language. They will make you stupid, and some stakeholders will sense their use.
6. Insist that stakeholders sign off on requirements before any work begins.
7. Append the CR with test scripts, including edge cases, of course. This also gives you a chance to test your modifications. I often wrote these scripts before sending the first draft to stakeholders.
8. Only release to production once the stakeholder has signed off on tests.

9. If the release process includes a DB schema change, be mindful that it may break the existing solution. In such instances, follow this three-step release process:

   1. Run a non-breaking SQL upgrade script,
   2. Upgrade the application,
   3. Run a SQL clean-up script.
   Test this and test AGAIN. Make a record that you have carried out the test, including the method.
10. Never release at the end of a day or the day before your annual leave/weekend.
11. Each CR gets its own folder. Name each folder as follows: {yyyyMMdd} {cr number} {descriptive name}.
12. Name files in folder as follows: {descriptive name} {yyyyMMdd} {version number}.

New Projects

1. Always aim to have a face-to-face consultation, if possible.
2. Agree on an MVP., i.e. the solution will do X, Y and Z.
3. Design the database model and other database objects. Don’t worry about UI at this stage. I've seen projects stall because developers get hung up on UI elements and layout too early.
4. Write a requirements document using the tone suggested above. At this stage, you can also sketch your UI.
5. Plan hosting environments and costs carefully, considering both setup time and expenses.
6. 6. Create a spreadsheet listing each atomic development/business unit, with estimated development time per unit in hours (be generous). Include an actual development time column. You can then do some Excel function jiggery-pokery to provide a rolling ETA. This step can be skipped for smaller projects, and a less granular time presence can be used for very large projects.
7. Send the document, spreadsheet and any other supporting files to stakeholders for perusal and sign-off.
8. This initial DB diagram, draft requirements, and spreadsheet should take about a week to produce, and about a week for stakeholders to review. Give them a nudge if it takes any longer.
9. Set up hosting environments.
10. Get coding, you hero!
11. Proactively give progress reports, using the data collected from your spreadsheet.
12. Test and deliver regularly.
13. Aim to get 80%-90% done in three months. The final 10-20% will take at least nine more.

Improve your Quality of Life

Create your own personal knowledge base. As well as coding scraps of knowledge, you can add domain-specific notes here too. Corporate knowledge bases tend to have issues (outdated or hard to navigate), so I do not like to rely on them.

So why did I say "used to work"?

Because somewhere along the line, the industry became ceremony-obsessed. We replaced thinking with frameworks, meetings and more meetings. Introduced more roles than outcomes.

Lean, sane ways of writing good software do still exist.

If you’ve made it this far, thanks for entertaining a maverick. Maybe you are one too. :-)