Wednesday, February 19, 2025

when "make it work, make it right, then make it fast" was wrong!

In a reflective mood today, I recalled a time when the "make it work, make it right, then make it fast" approach failed to work for me.

As part of a large-ish development team (about 20 developers, designers and testers,) I was tasked with building the data access component. It was a large, new application that was highly complex and also high profile. 

I was the first developer on the team and did some early experiments and research into the new platform we'd be building for and the new framework we were to use.

After a few weeks of R&D, I went on holiday (vacation.)

While I was away (and without my knowledge), work on the project started "properly". One of my POC/experiments was assumed to be good enough to start the work, and people were quickly added to the team. While all this was happening, the app's requirements were still being decided.

When I came back, I found people busy trying to implement the individual sections of the app they had been assigned and I was asked to work on the "common data layer" that would provide everyone access to the data they needed.

I was scrambling to provide the other developers with the data they needed while the other developers were also dealing with designs that kept changing and so needing new/different data.

I just about kept up, but as the requirements of the data retrieval and caching were still being decided and worked out, I focused on building a data access API that the other developers could use and could hide the caching such that no other parts of the code had to pay them much mind beyond being able to specify if and when cached data was or wasn't acceptable. (i.e. If the user has specifically forced/requested a reload of data, then don't rely on the cache.)

I repeatedly told people, "This is how you get the data. I know it's slow, but it will get faster. I'll add the caching once things get a bit more stable." 

I either didn't say this loud enough, or people didn't want to hear it.

One day, the project manager decided that I wasn't doing a good enough job with the data retrieval as it was too slow, so someone else was assigned to it. I was to work on something less important. The other person had already started making the changes and my opinion or thoughts on the decision were irrelevant. A decision had been made.

Very quickly, the other developer got the caching working. Things were stable by then, and the code was clearly laid out with comments and TODOs indicating what caching had to go where and how to implement it. I'd been leaving comments and notes for myself, so I knew what still needed to be done.

When the other developer showed what they'd done, they were praised as the savior of the data access code as they had done something I hadn't (and so it was assumed I couldn't.) My competence was also questioned: why hadn't I done something the other developer could do in a seemingly quick and easy fashion?


I had assumed that getting it right and then making it fast was the way to go. 

The powers that be wanted something faster, sooner.
They were also used to things having to be changed and reworked repeatedly until they were right. The idea that anyone could get the design right the first time was anathema to them.


What went wrong:

  • We weren't clear about goals and expectations.
  • Communication was incomplete.
  • We were working off different assumptions about what was required and what was good enough at the current stage of development.


What I'd do differently today:

  • Firstly, I'd try and avoid the situation where lots of people start working on a codebase where everyone is doing different things as we all try and learn a new platform, and while the requirements were still being established.
  • Be clearer about requirements and deliverables.
  • Be more transparent about my progress and expected deadlines.
  • Possibly, try and show something that mimics the complete final experience as early as possible. ('This part of the code shows what the final user experience will be like, but as these other parts are still in development, we haven't flipped the switch on ')
  • If there's more work than can be done in the time, establish prioritisation. ('I'm deliberately not focusing on the performance yet so I can ensure everyone has the data they need and isn't blocked. Once that's done, I'll add the caching. I know how to do it, and it won't take long, but I don't want to hold other people up. Is this Ok?')




The above all happened over a decade ago but still has relevance. ;)

Wednesday, February 12, 2025

Thursday, February 06, 2025

AI can't tell you why the code was written

I recently heard of a new "AI" based tool for developers that can explain both what a piece of code does and why.

The claim about "why" can easily sound appealing, but it is very open to misinterpretation.

It may be possible for the tool to explain why the code works, but it can't explain why the code exists.

It can't say why this code is the best way to solve the problem it exists to address or what the person using the software is trying to achieve.

It's necessary to know more than just the code to understand why software exists and what it does for the people who use it.


I know developers (and many companies) don't want to hear it, but it's necessary to record (document) more than just the code.


Monday, December 16, 2024

All software is change

The cliché says that there are only two certainties in life: death and taxes

There's a third: Change

It will happen. You can't stop it.

Change is anything new or different. This is core to what a software developer does. A new product, a new feature, and even a bug fix, will all involve changes for the person using the software.

Software developers are also well known for wanting to use the latest product, the newest framework, or the toolset currently being hyped on social media. All these new things will involve changes in what they do and how they do it.

Resistance to change is a natural response amongst most people. Or, to be more precise, unwanted change is resisted by most people. A positive change without the need for a lot of effort or disruption is normally welcomed.

When something changes, you may have to learn how to use the new version. There may be a negative consequence due to the time taken to learn the differences, but these will hopefully be outweighed by the benefits the change provides.

Very little software is written once, used, and then discarded. It's far more common for software to be developed over a period of time and for changes to be made to it once people start using it.

If you're involved in creating software, getting used to, and accepting, change is something that will benefit you in your career.

Sunday, December 15, 2024

"There was no runtime pack for Microsoft.NETCore.App available for the specified RuntimeIdentifier 'iossimulator-x64'" - Keep your file and folder names alphanumeric

As part of the testing I do for the MAUI App Accelerator, I have checks that valid (but unexpected) file names won't break anything in the extension.

I probably (based on the things I find) do more testing in this area that the MAUI team.

For example, I just found that you can no longer include an  underscore, at sign, or brackets (opening or closing) in the file paths of any files in you .NET MAUI projects.

Previously these characters weren't an issue.

If you want to know more, there's now a bug about this on the MAUI repo.


However, I expect that none of that is very relevant to you.

So, why did I write this blog post?


Simple, to recommend and encourage you to avoid such issues by keeping you file and directory names simple and only using alpha-numeric characters. (and maybe a dot/period. 😉)




I do the testing that found the change in behavior, not for the sake of discovering weird, outlying bugs, but because I want to avoid anyone using my extension to encounter such a bug and then raise reports that I need to spend a lot of time investigating. Ok, so I may have just spent a lot of time investigating something that no one will encounter (to create the bug report), but at least it didn't mean that a bug was raised on my project when I had no time to investigate. Also, at least to my mind, I'm focusing the limited time I have to support my open source projects on making sure they're robust. If you appreciate such projects and want to help me develop them more, please consider joining the other people who have sponsored me previously.