Dexter's Lab for Dev's

Recently I have been getting into an old classic from Cartoon Network, Dexters Laboratory. It contains many pearls of wisdom for any software engineer. Lets investigate them.

For those who have not seen it, it’s about a young boy genius who has his own laboratory inside his parents house and his sister Deedee is constantly breaking in and dancing, subsequently breaking all Dexters machines.
While watching I noticed that there are several engineer practices that Dexter either lives to or ‘tries to’ apply which relate wholly to software engineering as well.
So what are these practices:

1. Always write tests (episode 1.2)
Episode summary:
Dexter turns on a machine (mechanatron) which he realises tests failed on (“computer begin tests”). His choice to ignore the red warnings meant that when he turned it on it blew up in his face.
Key ideas:
- With any new feature, always write tests.
- Maintain them by making sure they pass before assuming feature works in real world.


2. Keep ur machines (or code) flexible by flexing them (all episodes)
Episode summary:
Every episode the lab is different, only truly good features are permanent.
As a side note keep any unruly siblings out.
Key ideas:
- With tests passing you can confidently refactor or try out different design patterns to see what works.
- By flexing the app in this way you keep it flexible to future changes.


3. Always keep a log. (Episode 1.5)
Episode summary:
Dexter builds a machine which goes wrong and opens a time hole for a Dinosaur to get through. His first reaction is to check the log to see what happened and why.
Key ideas:
- Logs are very useful, first point of call if a failure.
- The more logged the better but choose wisely.
- Keep away from Dinosaurs.


4. Security at every layer (all episodes)
Episode summary:
In Dexters lab every room and area is protected or guarded in some way. This ensures he has high levels of security in each compartment. If any one is compromised the others are still safe.
Key ideas:
- Securing each layer ensures no single attack should compromise all areas.
- Be defensive in you coding and always check argument data or and external.
- In the webs case always “validate input and escape output”.



5. Right tool for the job (all episodes)
Episode summary:
Dexter has a tool for everything. Whatever he needs he makes sure the exact right tool is available. From jet pack shoes to conveyer belt to help travel the lab.
Key ideas:
- Ensure using right too whether that is the language or design pattern, ensure it fits your needs from the beginning.
- Not always necessary to re-invent the wheel and sometimes can be damaging as existing tools do the job better.


6. Do not comit to something if you cant do it (episode 1.7)
Episode summary:
Dexter and Deedee enroll in a competition to become a real sidekick. Dexter says he will be his favourite heroes sidekick so when he fails, he falls into pit of misery and shame.
Key ideas:
- Understand the language of commitment, “going to” and “i will”.
- Same for devs. If commit to something better be sure you can do it else will have consequences.


7. Dont be afraid to ask for help (episode 1.10)
Episode summary:
Deedee points out Dexters way of life is wrong and he is missing out on life.
Instead of fighting it Dexter quickly realises she is right and does the smart move of asking Deedee for help how to change.
Key ideas:
- Only foolish people suffer in silence.
- There is a lot to gain from asking for help when you need it.
- Often you cant see a problem very well after staring at it for long, a fresh perspective helps.
- Dont feel like you can, or have to, do everything on your own.
- Collaboration is a big asset for success in software.


8. Take time to listen to warnings (episode 10.9)
Episode summary:
Dexters mission is to sneak into Deedees room and spy on her but before shrinking himself the computer warns him of possible hallucinations. Mission goes awoll as hallucinations take over. Dexter admits he should have heeded warnings
Key ideas:
- In software you can get technical warnings in a log or even mental warnings. Often these belong to the start of a dark alley. If you are writing code for a solution and find yourself thinking it mite not be right. Listen to your instincts and reevaluate your solution.
- The longer you write bad code the longer the dark alley gets until all that’s left is a mess.


To sum up:
So there you have it. Some of the useful principles that have been found in a modest cartoon. The likelihood is that the writers had entertainment in mind and not software practices, but you never know :)

More to come soon on software practices.

1 thoughts on "Dexter's Lab for Dev's"

Matthew M. Kaufman

WOW, This is an amazing analysis. LOL!!! I love the Title of this.

Leave a Reply