Monday, January 12, 2026

Dark IT Patterns: The Rainy Day Server Pool


Scenario
A team finds themselves constantly being delayed due to lengthy internal requisition processes and bureaucracy.

Problem
Projects are delayed due to internal bureaucracy. Important pieces of hardware and software are waiting on another part of the organisation to requisition them and set them up.

How it works
Instead of requesting the resources at the point they are needed, the team requests them at the start of their project, or at the end of their previous project. In effect, the team maintains a pool of resources, ready to be used by their next project.

A cost is shifted forward to well before it is actually needed, but the advantage is in the agility of project delivery. There could also be some costs to being on standby (e.g. monthly license fees or server electricity costs).

Real life
Due to team size scale up and release date pressure, this practice is common in game development studios. Its also common in government departments and larger organisations. It can apply for any sort of hardware or software - desktop machines, tablets, mobile phones, licenses for design software, server hardware or database instances.

The migration to the cloud has meant that servers are now a lot quicker to spin up virtually. So due to cloud IaaS, there is less need for this, especially for server hardware and database instances.

Corporate ethics
Its not really a problem in terms of ethics - its more like an indication that some processes in the organisation are too slow and should be improved.


Follow @dodgy_coder on X

Thursday, January 8, 2026

Dark IT Patterns: The Fall Guy



Scenario
A valuable customer is hit by a major intractable bug or a serious system limitation with your software.

Problem
Your company needs 6-8 weeks to resolve it, but the customer is demanding immediate action or else they'll walk away.

The plan
Get your company an initial 2-4 weeks of time with rounds of meetings and follow up meetings. At the same time, hire a business analyst (or project manager) who may potentially be out of their depth technically, but who can present well at a meeting. 

The new hire is given responsibility for representing the company's position to the customer, and asking for additional development time. At a final crunch meeting, put the new hire in the firing line to answer to the customer's main concern, e.g. exactly what is the technical plan going forward and exactly when and how will the issue be resolved?

Why it works
If they succeed, then you've got the required time you need to work on the solution, along with a truly useful new hire. If they fail, they are fired the next day, and now the customer knows you are serious about doing something. Due to the seriousness of someone being sacked, and the time needed to hire a replacement, the customer is willing to give you another month to complete the work.

Root cause
The root of the problem is just the reluctance of the company to end their relationship with a difficult customer - who they can't properly support. It can also be traced back to some out of control technical debt, resulting in an intractable bug.

Corporate ethics
No company should ever do this - it reflects badly on a company that they are willing to fire an employee for the sake of keeping one customer. This kind of behaviour is called corporate scapegoating, it needs to be called out for what it is and rejected by management.


Follow @dodgy_coder on X

Monday, January 5, 2026

Choosing between Flutter and React Native in 2026

This article summarizes the important factors involved when deciding between the two leading cross platform mobile development frameworks of Google's Flutter and Facebook's React Native.

Flutter

Advantages

  • ✅ It can design complex UIs which are standardized across Android & iOS resulting in less platform dependent bugs.
  • ✅ Easier to learn for existing mobile developers. 
  • ✅ Dart is a fully object oriented language, so is great for large enterprise size codebases.
  • ✅ Good debugging ability and hot reload.
  • ✅ A self contained easy to use IDE (Android Studio).
  • ✅ Quick ramp up time.

Disadvantages

  •  Dart is a new language to learn, and isn't used anywhere else except for Flutter.
  •  Skills availability in the market is not as good as React Native, although it is growing.
  •  All of the UI must be in Flutter - you can't mix native UI components with Flutter.

More suited to

  • 💡 Existing mobile development team.
  • 💡 Graphical or UI heavy apps.
  • 💡 Greenfield projects.
  • 💡 Minimum viable products / startups.

React Native

Advantages

  • ✅ Large number of resources and libraries available.
  • ✅ OTA (Over The Air) updates; updates to the app outside of the app stores. 
  • ✅ Knowledge of React can be applied to web development. 
  • ✅ Easier to learn for web developers.
  • ✅ Very good skills availability in the market.
  • ✅ Can be integrated with existing native UI components.

Disadvantages

  •  Command line JS-based toolchain.
  •  Javascript / Typescript is not as suitable for very large codebases as is Dart.

More suited to

  • 💡 Existing web development team.
  • 💡 Migration of an existing app, with the ability to keep some native UI as is.

Follow @dodgy_coder on X

Saturday, October 5, 2024

The Art of Developing Software

The below is taken from an interview conducted at the Computer History Museum in 2004 by Grady Booch. He interviewed early Apple developers Bill Atkinson and Andy Hertzfeld about the development of the original Apple Mac, and in particular MacPaint software.

On the art of developing software

Grady Booch: So what makes software beautiful for you? Do you care about the beauty of software?


Bill Atkinson:
Oh yes, it’s an art form, like any other art form, and it’s not just practical, as in, does it do the job? Is it clean inside, does it look--? I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. 

I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing, that there’s nothing tricky in it, that it’s all very straightforward. And maybe that was a little bit counter to what I ran into when I first came to Apple. 

There were a lot of people who prided themselves in how this little piece does something that I can’t for the life of me figure out what it is, but it’s magic that it does it. I would do things like deliberately assign something into a variable, and instead of putting ten operations concatenated onto one line, I’d use intermediate variables so I could understand the purpose of each of these. And I liked it. 

I found that if I spent time going over the code, cleaning it up, making it sometimes tighter – I did a lot of measurement and tried to make the performance good – but also making it so that it was straightforward so another person could follow in my footsteps, then I would feel proud of it.


Grady Booch:
Don Knuth was telling me that he felt that MacPaint was perhaps one of the most beautiful programs he has ever seen, just in terms of its readability. 


On the MacPaint development process

Bill Atkinson: I had a different method of software developing than Randy Wiggington who was developing MacWrite. We had two different philosophies. Mine was you don’t get to add any new features until what you’ve got is working reliably, solidly; and his was, let’s add all the new features and then let’s debug them. I just think that that’s a bad way to do it because finding bugs is a very unlikely proposition. If you search really hard you might find half the bugs that are there, and the others are going to bite you and you just don’t know when. So I had a little more conservative approach to design.


Grady Booch:
What you describe is very similar to what the Agile community speaks of these days; always have something executable through incremental development. And it’s very cool.


Andy Hertzfeld:
Yes, yes, that’s really how the Mac was developed.


Grady Booch:
You were the first Agiles. So by my count, or others, MacPaint was about 5,804 lines of Pascal and so on; 2,738 lines of assembly language.


Bill Atkinson:
Plus all of the QuickDraw I’d built on top, because without QuickDraw you couldn’t do all that stuff.


Grady Booch:
And pretty much everything had built upon QuickDraw.


Andy Hertzfeld:
Yes.


Bill Atkinson:
There were 70,000 lines of assembly language [in QuickDraw]. 



More reading

Computer History Museum: Oral History of Andy Hertzfeld and Bill Atkinson
Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, by Andy Hertzfeld
Folklore: Anecdotes about the development of Apple's original Macintosh
BYTE Magazine (1984): An Interview: The Macintosh Design Team

Follow @dodgy_coder on X

Thursday, October 3, 2024

Alternative to becoming a Full Stack Developer ... Become a Generalist

Starting out
When you're starting out your career as a software developer, you'll typically get a first role as either a backend or frontend dev, and after a couple of years, gain some experience on the other side to become a full stack developer.

Company specific lock in
Since every organisation has its own tech stack, a full stack developer in Company A will have a different set of skills than one in Company B. Those additional skills you learn are still useful to boost your knowledge - it can include: specific cloud services, CI/CD, containerization, DevOps processes, a domain specific library or framework, and the company's SDLC process. 

At this point many developers stay committed to their company's tech stack and remain working as a full stack developer for several more years. My advice - don't just coast as a full stack developer,  branch out!

Branching out
Don't limit yourself to web apps.. branch out as soon as you get the chance, by getting some experience with any of these (if possible as part of your day job)...

  • Native mobile app development (Swift or Kotlin)
  • Cross platform mobile app development (Flutter or React Native)
  • Desktop app development
  • A newer backend programming language (Golang, Rust or Elixir)
  • AI & ML
  • UI/UX design using a tool like Figma
Some other ideas (which might need to be in your own time)...
  • IoT (Arduino or Raspberry Pi)
  • Game development (Unity or Unreal)
  • Blockchain development 

Become a generalist
Your aim is to become a generalist - someone who has deep knowledge in two or more areas and maintains a broad knowledge across many platforms, languages and frameworks.

After becoming a generalist, you'll be able to switch up your job roles, stretching your capabilities a bit each time you move. You'll find that you can apply for a larger variety of roles, increasing the possibility to land your dream job. 

Adapt to new roles
Your varied knowledge will make it easier to apply your skills in new and unfamiliar areas, building up after some years to become a senior developer. Once there, its possible to remain at the senior level for an extended period - as long as you still enjoy it and are still learning, why not.

Career progression
Eventually you might try for a tech team lead or software architect role. Software architects often started out as generalist developers who gained enough varied experience to be able to apply their software design skills into any domain. Tech leads can have a similar background, but they maintain more of a hands on development focus as part of their role, getting involved especially with creating proof of concepts. 

More reading
Generalist vs Specialist - the difference
Bill Gates on the book "Range: Why Generalists Triumph in a Specialized World", by David Epstein 
"The Polymath: Unlocking the Power of Human Versatility", by Waqas Ahmed
"Polymath: Master Multiple Disciplines", by Peter Hollins
What It Means to Be a Software Architect — and Why It Matters
Following the Software Architecture Career Path

Follow @dodgy_coder on X



Thanks to reddit user -NewYork- for this meme

Sunday, September 29, 2024

Which .NET ORM - Dapper or Entity Framework?

Within the .NET ecosystem, two ORMs dominate, the lightweight Dapper (open source) and the fully featured Entity Framework (EF) by Microsoft. 

Depending on your project's size and requirements, either of these should work well for you, but there are definitely some known cases where each is a better fit. That's what we're discussing in this post.

When to use Dapper?

  • Small to medium size projects. It has low overhead in terms of setup and configuration.
  • The database tables are in place already and you're calling existing stored procedures. This is known as a data first approach.
  • You prefer to hand code the SQL for speed, optimization or fine tuning.

When to use Entity Framework?

  • Its a large and/or enterprise type project.
  • The database hasn't been created yet and you'd like to use a code first approach. The framework will create the database for you after you code the data models.
  • You want the ORM to handle transactions for you in the background.
  • You need to use the power of C# LINQ (Language Integrated Query), whereby SQL joins and other queries are generated for you based on your C# code.

Other important factors

  • Is your project likely to change frameworks, or need to be adapted to other databases? If yes I'd favour Dapper, because there's just less to migrate and configure. Dapper tries to not get in the way. There are no  additional abstractions and class models that happens with EF.
  • Are you using .NET Core? Its probably a controversial opinion but I feel that .NET Core as a framework is still quite unstable compared to the original .NET Framework. So when a new version comes out, there's normally breaking changes within EF Core. For that reason I'd also favour Dapper over EF for .NET Core projects.

What's not a factor?

  • Speed and performance. There's no longer any significant performance difference between Dapper and EF. Issues with performance are more likely to be something else that's not being done correctly at the SQL level, such as a lack of indexing, or an incorrect query.
  • The origin of the framework. The first release EF for .NET which came out in the 2000s had terrible performance. Since that time, all the performance issues have been fixed.

Sunday, May 15, 2022

What the LUNA cryptocurrency has in common with a Thanksgiving Turkey and the LTCM hedge fund

A classic black swan event has just happened to the LUNA cryptocurrency.

A black swan event is characterised by a spectacular run up in price, followed by the price falling off a cliff to near zero.

It famously happened to a hedge fund named LTCM (Long Term Capital Management) back in 1998. The resulting loss temporarily destabilised Wall Street, requiring a bail out to be organised by the US Federal Reserve.

For LUNA, as with LTCM, a group of the smartest people in the room had banded together based on the unstoppable winning formula of:

(new technology + maths + programmers + marketing + chutzpah) = profit

Then claimed they'd solved a previously hard and intractable problem, and that everyone who doesn't believe them can just STFU, or in the case of Do Kwon (the founder of LUNA), "enjoy being poor". Oh the karma.

The risk with crytocurrency in particular is that if there's a bug in the algorithm or protocol, the result can be both an immediate financial loss, and a catastrophic loss of confidence in the currency. The bug can go unnoticed for months or years, before someone finds it and then patiently sets things up to exploit it for maximum profit.




Follow @dodgy_coder on Twitter

More reading:
How Terra's UST and LUNA Imploded (Decrypt)
Roundup of theories on the LUNA crash (Fortune)
'Evil genius' may have caused Terra and Luna to crash in a 'death spiral' (ABC Australia)
Long-Term Capital Management Hedge Fund Crisis (The Balance)
The Black Swan by Nassim Nicholas Taleb - Summary and Analysis (Get Story Shots)
The Black Swan Theory (Wikipedia)