Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever…

A computer scientist and an engineer (both unsuitable for the task) made grand remarks and provided their ill-informed opinions to the King. The computer scientist described a useless product, and the engineer promised to deliver a working model in a week. The King, being a dick, had the computer scientist thrown into the moat. With knowledge of the engineer’s upcoming prototype, everyone lived happily ever after.

Clearly this is just a fantasy, and they did not live happily ever after. The computer scientist was in no position to engineer a product and it was unfair of the king to demand that they did. Emerging from the moat, bruised and embarrassed, the computer scientist filed a suit against the kingdom. Meanwhile, the engineer had completely underestimated the complexity of toast browning dynamics, the toaster’s embedded microcontroller had a naïve toast-level-lookup table which wasn’t consistent across all slices of bread.

The King wasn’t happy but decided to proceed with the toaster project anyway.

The engineer got back to work and decided that the toaster required thermal feedback which would help with the browning calculations. This required the addition of a temperature sensor and an 8-bit processor to sense the outputs on from an analogue-to-digital converter. The prototype toaster project was now delayed by 2 weeks while the requisitioned hardware arrived.

Once in possession of the ADC and the 8-bit processor (with increased pin-count to allow reading all 8-bits of the ADC), the engineer proceeded to build the toaster and took it to the King to demonstrate.

Even with thermal calibration, the toaster was inconsistent. The King reluctantly approved the demo as a proof of concept but ordered that the toaster project address the browning issue. A computer scientist was hired at massively inflated contract rates to help for a couple of weeks.

A junior developer was also added to the team for … reasons?

The team set to work rectifying the issues with the toaster and determined that the resolution of the ADC was insufficient to detect the slight temperature variations that introduced browning inconsistencies. A 12-bit ADC was agreed-upon, but the team couldn’t decide whether to use a PISO shift register or specify an ADC with a serial peripheral interface. Finally, the toaster team decided to go with the shift register and developed their toaster prototype.

It toasted bread well, it was consistent and accurate.

A royal demonstration was called, and the showed off their new creation to the King, who was very excited by the progress. The King immediately ordered a beta test.

Citizens from the kingdom were chosen and provided with toasters to test them out.

The feedback was lacklustre.

For starters they had an issue understanding how to use the knob, and the lever just didn’t seem quite right either.

A product owner and a scrum master were appointed. Another junior software developer was added to the team.

The product owner sought counsel from the nobles of the land and brought forth user stories about a visual ‘toast intensity’ indicator and a multi-purpose toast lever that could also lift the bread high and reduce the likelihood of burns.

A requirement was added to allow the optional cooking of bacon, and pork sausages.

The (now agile) team sprung to action, planning their upcoming sprint. A decision was made to drop the bacon & pork function as time would not permit. The knob was replaced by a ‘toast intensity slider’ with a visual indicator of LEDs, coded to show how far along the slider was - when the slider was halfway along, 8 of the 16 LEDs would light up.

Upon completing the next iteration, the PO and nobles met to discuss the progress. The nobles couldn’t understand why the bacon function wasn’t delivered. They were adamant that cooking bacon was harder than cooking toast, and they couldn’t really see themselves using the toast function all that much - toast was for commoners after all.

The product owner promised bacon functionality would be scheduled for the next iteration.

The team, quite disheartened, argued about how to implement the bacon feature and eventually agreed that it could be done if constraints were placed on the bacon and developed the feature.

The nobles reminded them they had also agreed to pork sausage.

The project was now 12 weeks overdue. The original cost had blown out by a factor of 20, and the toaster-oven was still 2 weeks away. The original engineer and scientist were fired from the project.

A new junior developer was added to the team.

The development team ran in to unexpected issues with bacon grease and sausage shapes. The missed their 2-week sprint deadline. The scrum master quietly blamed the influx of junior developers, and the product owner dutifully passed the message back on to the nobles who weren’t impressed with how the ‘boffins’ were running things.

Iterative development continued but there was no viable product on the horizon.

A decision was made to abandon sprints but “keep everything else agile”. This was done to make it easier for developers to focus on the R&D with longer timelines. They used the time to work out how to cook pork products.

Finally, after months of delays and massive cost blow outs, the toaster-oven was working. But it was not very good at cooking bacon or sausage. So, a carefully choreographed demo was created, and the product was taken to the King’s chambers for review.

The product owner demonstrated the toasting feature (which was still working as expected), and the newly developed bacon mode.

The King was delighted, asking many great questions, which unfortunately lead to the product owner going off-script and burning some eggs.

“Not to worry, this is great progress”! The King said, sending the development team off with smiles and handshakes all-round.

The team continued to work to refine the product, developing a robust toaster-oven solution.

The codebase was becoming difficult to manage. A refactor was agreed upon.

Several months pass by and the toaster-oven development team still haven’t heard back from the Palace. They sent messengers with queries, asking if there was anything else the Palace required for the project to “go live”, but they didn’t hear back.

Time passed, and two months before the next royal jubilee, the jubilee planning committee reached out to the toaster-oven development team and announced that the oven would be demonstrated to the citizens of the kingdom during the celebrations. The team was delighted.

The jubilee planning committee requested a demonstration so they could determine how to best showcase the Palace’s fine work.

Four weeks before the jubilee the team gave their final demo. The jubilee planning committee was very excited by the progress but wondered where the egg cooking feature was. The product owner assured them that the feature would be done in time for the celebrations – the committee left satisfied.

Morale in the breakfast-maker development team was at a low. There was no way the egg cooking feature could be done in time, but they agreed to give it a go.

The team worked around the clock, all night and day, toiling to produce the breakfast-maker. They struggled with eggs leaking throughout the product and the bacon grease issue re-appeared. The toaster was no longer toasting consistently either.

Through a combination of luck and hard work, the breakfast-maker was ready in time and the team was sure this would impress the crowds. The new breakfast maker featured a fast processor, touch screen interface and made a reasonable toast.

This time, sticking to a well-rehearsed demo, the team presented.

The jubilee was a great success and the citizens of the land all left, excited by the Palace’s ingenuity and ability to develop such an amazing product.

Time went by. Nobody heard anything. Most of the developers had moved on, and the team no longer contained any of its original members.

The breakfast-maker team contacted the Palace again, requesting an audience with the King. They had run out of resources to further develop the project and were seeking a final sign-off so they could make the breakfast-maker go live. They were granted an audience, and a date was set for 4 weeks.

Over those 4 weeks, team worked to polish the features of the breakfast-maker and took it with them to the Palace.

Unfortunately, the King had taken ill, and the team would be meeting with the prince (heir to the throne). The prince was not aware of the breakfast-maker project; however, he listened politely and watched the demonstration – albeit with some lack of interest or enthusiasm.

The prince liked the toast feature, and the sausage cooking was working ok. A junior developer demonstrated the touch screen UI and then showed the prince a cheeky easter-egg that could appear if you clicked a certain combination of breakfast foods – the oven could launch and play the game Doom. Everyone had a great laugh! The prince agreed the work was of good quality and he would pass on his recommendations to the King.

The King died.

Oven the coming months, the kingdom mourned, and the prince was crowned king.

As the new King, the former prince requested a full audit of the Palace’s spending. The toaster project was identified as being severely over budget.

Summoning the breakfast-maker team to the Palace, the King asked why the toaster project had run so far over. The team explained the development history and the additional requirements. The new King listened, still not convinced, but agreed that so many resources had been sunk into this project that it would make more sense to wrap it up nicely. He wondered what it would take to ensure it also could run Doom like he saw in the demo.

The team agreed this would be a great feature and set to work improving the game-console-breakfast-hub.

A new junior developer was added to the team.

Months passed as the team wrestled with game engines and hacked together a working prototype of the game-hub.

Meanwhile a new start-up had appeared on the scene. They had noticed that the citizens of the kingdom had no easy way to cook bread. So, they decided to Kickstart the Open-Source-Toaster which they called The OSTer.

The Kickstarter was a great success, it’s just what everyone wanted – the ability to toast bread!

With its goal reached, the start-up assembled their team of engineers, computer scientists and software developers and set to work on OSTer. Their goal was to make sure the masses could toast bread with an easy device that was also affordable and provided open APIs to allow other developers and users to implement their own controls and features.

The deadline for delivery came and went.

The citizens of the kingdom understood that sometimes these projects take time.

Months passed, the OSTer team posted a video of their progress, showing the OSTer making a bacon sandwich. Though in reality, the OSTer could only cook bacon OR bread, not both. For the video two OSTers were used, and they had to be manually configured for bacon-mode or toast-mode. But, as this was just a proof of concept, there was no need to worry, the core OSTer features will be delivered before the new year.

New Year came and went.

The citizens of the kingdom understood that sometimes these projects take time, and they looked forward to cooking bacon and eggs on their OSTers.

Months passed.

The OSTer team posted a blog showing the first OSTer being packed and ready to send. But wide-scale distribution of OSTers to backers was still a few months away, the OSTer would ship to all before Q3.

Q3 came and went.

The citizens of the kingdom understood that sometimes these projects take time. Some recipients of early OSTers reported their houses had burned down due to unexplained electrical fires starting in their kitchen.

The OSTer team took to X (formerly Twitter) to deny the OSTers devices were involved in the fires. They accused backers of being petty, aggressive and “ignorant of correct OSTer usage techniques”.

The citizens revolted, the OSTer team had burned through any good-will that remained. The encounters between the citizens and OSTer became increasingly hostile until the project fell silent, having delivered only a handful of the promised OSTers.

Time passed.

The Palace was preparing to release their second game’s console after the lacklustre performance of the first console. Tech journalists questioned the Palace’s credibility as game console developers and decried the game-hub-v2 as “lacking innovation”, and “unable to compete with existing consoles”.

The Palace released GH-V2 in time for Christmas and sales were as predicted, not great. The Palace acknowledged users deserved better and that they would do better. They returned to development of GH-V2 patches and minor upgrades.

A new junior developer was added to the team.

The GH console was re-vamped, with faster hardware. The development team started running in to heat dissipation issues; one of the team joked that it was almost hot enough to toast bread, also demonstrating they could fry an egg on the heatsink - the video leaked and the Internet became excited about a games console that could also cook breakfast.

If you’re waiting for a punchline to this story, don’t. This is the story of innovation. It never ends. It takes teams of people, unreasonable users, and unexpected challenges and visionaries to develop great things…

…

Unfortunately, as a citizen, you still can’t toast bread, the upcoming GH-V3 can no longer run Doom, your Kickstarter money is gone, and your tax dollars have been spent on projects you’ll never see.