DEV Community: Lee Nattress

Dangerous Prototyping

Lee Nattress — Thu, 22 Jul 2021 07:54:23 +0000

Goals

Find out if we can solve the problem at all

If we have a problem where we don't know if we can solve it, a prototype allows us to attempt it with the least risk.

We need to try something to be sure we can solve it, and the business needs to know this because the solution normally results in a return for the business.

It's a risk we take ahead of time, to mitigate the larger risks later. We are trading a small amount of time now, for a huge saving and a big confidence boost in knowing we can execute a solution well.

Find out if we can do it in good time

After a prototype, we can see if the final solution is worth it. Will it cost too much time and money?

How far will the final solution be from the prototype?

Always be aware of the difference between the best possible way of executing the solution and the state of the prototype. This distance is how far you need to go after you have proven you can make it work.

Find out if we have the skills in our team

Can we find the people we need with the skills to execute the prototype, but more importantly, the final solution.

Sometimes we find hidden skills in our team that lets us solve something, in a non-standard way. Something our regular development process might miss.

Think of prototyping like a business sanctioned hackathon with a specific goal.

Dangers

Technical Debt

The prototype is not the final solution, every step we take, and every line of code written is technical debt, for which we can assume all of this might not be used.

We must think about how we might deploy a final solution, and who will maintain it during prototyping, so the distance between this and the final product is shorter. We must do ourselves a favor in the future.

Your solutions should be Cattle and Not Pets.

Always maintain a technical debt log, where the business can see it. You must make any stakeholders aware that a prototype is just that, and not an MVP or other directly usable solution. The business will try. This is a very dangerous thing. Stand your ground.

Temporary Permanence

If a prototype does end up being used in production there is a real danger that this temporary solution may end up being a permanent part of the infrastructure. Though this sounds exciting for a business addicted to features, this means that additional infrastructure will spring up around it to deal with the difference between the prototype and the correct solution. API, operations, support teams, help documents, the whole nine yards. This should obviously not happen.

Communication is key. We must let the business know that the prototype we made is not the final solution, and that putting off the cost to them of creating something more permanent will cost more in the longer run, due to the work done around an incomplete prototype to make it fit in and work.

Testing a prototype all the way is not always in the cards. Regardless of how much QA complains, we need to know if we can do a thing. We are removing the fear of if we can, not making a final product.

The bigger picture

If a business ends up with several prototypes in production, due to its need to release features, then this series of incomplete, unstable or untested solutions will create a mesh of difficult to replace and interconnected workarounds and technical debt.

As a business owner, you need to learn to acknowledge that creating a prototype is just that, and that you must assume that all the wires need to be pulled out and the real solution built again with the things you've learned.

MVP fever

It is so easy for a business to see an impressive product demo and make the assumption that this is a complete solution. The technical parts in between, or even the reasons why it is a bad idea to assume this is a minimum viable product sometimes escape product owners and project managers. It is your job as an engineer to help them to understand the cost they will incur in the future if they do not heed this warning.

It's very common for a full test suite to be missing from a prototype, since testing is not always part of making sure that something is technically possible. This should be part of your technical debt log. If it's testable, test it. The final solution must be tested properly.

This of course has it's own problems. If you omit full testing because your prototype is to prove a point, and the business takes it as a product because it got carried away with the stakeholders, then it will be missing the full suite it needs in production. This is dangerous and happens a lot, so watch out for it.

Benefits

Learning new skills

Doing a prototype to see if we can, forces people to step into unknown territory, and you may find that either you or your team needs to take on a technology you've not used before.

Sometimes, it's even an experiment in a totally new technology. This is absolutely essential for a business to thrive. It is for this reason that I consider prototyping to be one of the most enriching experiences for engineers.

We may also learn new ways to work as a team, and I can assure you, you will learn new skills that you did not know your engineers had. You will find skills they have in tools you had not considered.

Make notes of the things you need for Toolsday.

Becoming braver

We will become more brave. Learning that a thing is possible makes us more confident that the product we will make with the learning we took from our experiment will be the best we can build.

We will make stakeholders more confident and we will be on the right track technologically. It is a win-win for everybody involved.

Apart from the person who pays the salaries. There is a risk that we wont learn everything we need, or that, we are wasting our time and we should dive into making a different solution.

We have to get brave here too. We may fail and we may make poor decisions about replacing the prototype before launch. We have to be stronger here if your leaders think this way.

Teamwork

It's dangerous for a prototype to be made by a single person, even though from the perspective of the company, it seems like a sound strategy. Take a single person and get them to take a risk for the business. If it fails then you're only losing one person's time and this seems like a more acceptable loss.

This needs to be a team effort. If parts of this solution or ideas from it become a new system, or the lone designer of the prototype leaves or is re-assigned then there is a risk that we will have learned nothing from the prototype phase.

Mob it as a team and learn as much as possible.

Seeing the future

Although a prototype should prove we can do something in a reasonable time for the business, we should also bear in mind the future and what it holds for the correct solution, and how that might be used in the business.

Plan the final solution and make sure this is part of the prototype too.

This sounds backwards, but think of this example:

If we make a system that adds two numbers but we ignore the fact that we will be calling it with a REST API, then we are missing the point. We need to make a REST API that adds two numbers.

Don't ignore the simple requirements of the final product in your prototype.

Key Takeaways

Prototyping is about mitigating risk

You may think you already know the best way to do something because this is how you have always done it. You are very wrong. There are all sorts of better ways to solve problems.

The distance you have between the ideal solution and your prototype is your technical debt. Always plan to close this gap, as soon as you can.

Don't let a lone hero do a prototype. Work on it together, you all need to learn how it was solved.

The thing you make is not forever, it only exists so you can prove its possible. The longer you hold onto the prototype, the more expensive it will be for the company in the long run.

Whatever you do, do not ever put the prototype into production, its not good enough, it never is.

Get brave and try wild ideas. Nobody ever wrote amazing solutions playing it safe. Nobody.

Can you turn this into something production worthy later? Keep your eyes on the prize. Don't do things that trap you in the corner technologically or operationally.

Code like a Klingon Warrior

Lee Nattress — Thu, 22 Jul 2021 06:49:47 +0000

The definition of honor varied widely between cultures, as did the importance placed upon it. Honor was normally synonymous with dignity and referred to the upholding of one's values. The Klingons were notorious for the emphasis they placed on honor.

No code is correct at first

If you cannot fail, you cannot succeed.
bIlujlaHbe'chughbIQaplaHbe'.

Any code we make can be re-written, replaced, refactored or even straight up removed. This is the way of code and so you should try not to get too worried about perfect code straight out of the gate.

Solving the problem in your story is enough to grant honor, but try not to get too hung up on the efficiency of those few lines, or if you think something is the right way.

In code review, your team will help you understand. There is no shame in having code changes requested. This is how we learn. Do not let pride stand in your way to victory.

Write honorable unit tests, help your team.

When a warrior goes to a battle, he does not abandon his friends.
may'DaqjaHDI' SuvwI' juppu'Dajlonbe'.

Get your unit tests to pass. If you do not do any tests you bring great shame to your house and your family. Passing bad code to another warrior will secure your place in Gre'thor where Fek'lhr awaits the dishonored warriors.

Without testing, your code cannot be verified as functional and if you deploy this code into production, you will see defects.

Without tests, other warrior coders might change your code, only to find it creates bugs or problems that could not be found until later.

Go straight for the kill, solve the problem

Klingons do not procrastinate.
lumbe' tlhInganpu'.

When fighting alongside other warriors, we must keep our eyes on the prize.

Work together on problems, to solve the ones right in front of you as soon as possible, to provide value for your team, and the business. Defeat your enemies together and do not spend time on things that do not relate to victory.

Clearing blockers for others is honorable

If it's in your way, knock it down.
DubotchughyIpummoH.

Klingon warriors fight together, as a team. What is in their way, is in your way. When a fellow Klingon is fighting an enemy, even if this enemy is not yours. There is no greater honor than helping another Warrior reach Suto'vo'qor.

Your SCRUM master might be the one directing the team to release blockers, but it is your duty to help them and step in when others need help.

If you help others defeat their enemies, then they will help you defeat yours.

Klingon coders write great documents of their deeds

Great deeds, great songs.
ta'mey Dun, bommey Dun.

The Warrior's Anthem:

Qoy qeylIs puqloD.
Qoy puqbe'pu'.
yoHbogh matlhbogh je SuvwI'
Say'moHchu' may' 'Iw.
maSuv manong 'ej maHoHchu'.
nI'be' yInmaj 'ach wovqu'.
batlh maHeghbej 'ej yo' qIjDaq vavpu'ma' DImuv.
pa' reH maSuvtaHqu'.
mamevQo'. maSuvtaH. ma'ov.

For every great victory a Klingon warrior has, songs are sung in their honor.

Your system, product, repository or idea needs great documentation that will be used long after it is written. Your documents should be brave and true, written so that it tells a story of how your system was made, and how it should be used.

All great warriors, sing songs of their code. If you aren't proud of it, then it was never good code. Make your code and documents in such a way so that will be proud of them and other warriors will sing of your battle for generations.

Klingons and Agile:

"Nothing is more honorable than victory." - Worf

Defeat each enemy on your way, and celebrate victory with song.

Fighting all your enemies at once will bring defeat, and shame on your house. Pick your battles, and after each one, learn your enemies weakness. Every time you engage the enemy in battle, you will have learned from their fallen, how to deal with the next.

Sing songs of your battles and those that come after you will not fall into the same traps as you did, bring honor to your house and learn from the fallen warriors that came before you.

Satisfy Kahless Through Early & Continuous Victory
Welcome Changing Requirements Even Late in the Battle
Deliver Victory Frequently
Break the Silos of Your Bird of Prey
Build Wars Around Honorable Warriors
The Most Honorable Way of Battle is Face-to-face
Victory is the Primary Measure of Honor
Maintain a Sustainable Fighting Pace
Continuous Honor Enhances Agility
Simplicity is Essential for Victory
Self-organizing Warriors Generate The Most Victory
Regularly Reflect and Adjust Your Ways of Combat to Boost Effectiveness

Destroy your Sprint Goal Like a Warrior

Focus on but one target.
wa' DoSneHyIbuS.

All great warriors will head straight for the sprint goal, because this is where the greatest honor lies. Defeating the goal with your brothers and sisters in battle will secure your place in the great hall with Kahless the Unforgettable.

Do not be distracted by other trivial things, and keep your eyes on victory at all times.

Strategy and tactical prowess will beat the sprint goal, not mindless bashing at the keys

Brute strength is not the most important asset in a fight.
Suvlu'taHvISyapbe' HoSneH.

Brute force alone might win the battle, but strategy will win the war.

Fight smarter and use your time wisely. Determine battles you do not need to fight and move on to greater challenges.

You will bring great honor to you your house if you can find better ways to achieve victory.

Stay on top of your game, always keep learning

Even the best blade will rust and grow dull unless it is cared for.
'etlhQorghHa'lu'chughragh 'etlhnIvqu' 'ejjejHa'choH.

Only a petaQ would think their skills with the blade are ever enough!

Always learn more of your enemies weaknesses to meet them in the field of battle. A Klingon warrior's greatest ally is his keen knowledge of the enemy.

Always learn new combat skills, there are always new ways to defeat an enemy.
Bring honor to your house by sharing your warrior's teachings with others.
When you fight the enemy, fight together with a close ally. Take turns to lead, while the other backs you up. This way you can learn from each other.
There is no shame in admitting you cannot handle a new weapon. Seek a great Dahar Master to show you the new blade's true power.

Protect your code, technical debt is the enemy

May you die before you are captured.
Dajonlu'pa' bIHeghjaj.

If you do not completely defeat an enemy, they will lie in wait, and their wrath will be tenfold when you meet them again.

Always keep your code clean and as you open a file, be honorable and fix any problems you see. At some point, an enemy you thought you had defeated will be a problem for you again if you do not completely slay them.

For the empire to stay strong, write songs of your deeds, but also pay special attention to the enemies you could not slay at that moment.

Come back later and finish them off.

For glory!

Establish your own Code of Honor

Now it is your turn.

Pick up your bat'leth or d'k tahg and practice a code of honor. In your Klingon hearts you know what greatness looks like. They will sing songs of your great deeds.

Qapla'

80/20 Rituals: Happy Toolsday! 🛠

Lee Nattress — Thu, 14 Jan 2021 10:07:08 +0000

I've heard both sides of the argument for the 80/20 rule with respect to software delivery. It's simple to explain, you see as developers we are supposed to work 100% of the time on the thing we are told to work on. This is often spread over several tasks, like meetings, planning, meetings, development, meetings, and meetings.

80/20 tells us that if we work 80% on the thing we are told to and 20% on something to benefit the company or project in some way. This is basically one day per 5-day working week.

To some managers and companies, this is abhorrent. It means the client gets only 80% of the developer's time but is paying for all of it, or even worse, the company pays 20% 😱

Managers in such an environment, who don't understand the power of letting creative people off the leash will often cite that developers will 'bunk off' or do nothing in their 20.

And some of them might.

In this case, you've hired for ability and not ability+culture. Developers uninvested in the outcomes of projects will not give you their all, they won't be bothered if you succeed as a business.

Emotional investment comes in these forms:

1️⃣ Relationships with others
2️⃣ Ideas and ideologies
3️⃣ Membership of groups
4️⃣ Pleasures such as listening to music and hobbies
5️⃣ Development of ourselves and our careers

We need to do something with developers to give them as much and as many of these things as possible, so that their motivation is in alignment with your goals, as a manager.

There are many ways to use the 80/20 rule but this is the one I like the most:

Make anything you want, but do it as a team and have it benefit the company in some way

The idea here is that people form into two or more person teams and work together, one day a week.

Here is a visual example, in case this talk of tooling is confusing:

Let's assume you are in charge of a team of miners who are digging for diamonds deep underground. Every day they produce value, at a steady rate, with their pickaxes, removing the rock from the rockface and uncovering diamonds 💎. Your research has shown that there are a lot of diamonds still in there, far into the rock. Your boss is happy because you bring them diamonds but always wants a higher quota.

In the mine, there is a room full of machinery, pipes, motors, batteries, drill heads. Just sitting there.

You don't have time to assemble them. If you stop, the boss won't is happy. They will want to know why he gets fewer diamonds, every day the miners aren't mining.

The miners tell you daily that there are better ways of doing things, and that digging by hand is inefficient. One day you take the risk and tell them to spend 20% of their time building a drilling machine. They get to work, as a team.

Initially, productivity drops. Or does it? It turns out that they weren't working 100% of the time anyway! A lot of it was meetings and having their time zapped away by all manner of interruptions.

Streamlining their time and protecting it when they are working means that the drop in productivity is not hurt much, you were just overly worried.

After a week or so, the first innovation comes from the effort. An agile response, an MVP: A sharper pickaxe.

Then a scanner to find diamonds quicker.

Then a mechanical drilling platform that can rip the diamonds out of the rock face 💎💎💎💎!

Guess what happened to your productivity? and guess how happy your boss is? Now, guess how much your miners are invested in the project, now that they have had input and their tools and ideas are helping you produce output?

For the sake of comedy, let's call it TOOLSDAY. Let's have it on TUESDAY 😅

As a team leader, lead, or manager, it's your job to protect the developers in this time, and encourage them to build. Their projects are not for you to judge, meddle with, or change the projects and ideas they have.

Your job is to:

1️⃣ Get your team working together to solve a common goal, helping and teaching each other.
2️⃣ Generate new ideas, frameworks, and tools that they agree on together and can own that thing.
3️⃣ Be part of something other than the team they may work with every day.
4️⃣ Have an opportunity to bring their existing skills from a development-related hobby they have or something they don't use every day because it's not part of your company's toolchain.
5️⃣ Learn new things, explore new and scary things, and conquer them with help always present.

See what we did there? 😉

Here are some examples of things I've seen made in the past on Toolsday and if they benefitted the company (hint: They did, massively).

Tools that automatically generate code scaffolding, saving time, and automating mundane tasks.
Libraries that abstract away complex functions allowing complex features to be used in a simpler way, de-skilling the requirements from this point forward.
Re-usable component libraries so that you don't need to write the same boilerplate forms or widgets ever again.
'Ted talk' type days and events to directly impart learnings and give people confidence.
Frameworks that speed up delivery by guiding design and development, making consistency the word of the day, and allowing things like time estimations and confidence to increase.
Testing templates that can be applied again and again to stop re-inventing the wheel and bring teams to one place to design.
Developer blogs that let teams talk about the why and say something bigger than the monotone sorrow of commit messages, to bring humanity into your projects and let people explain their decisions.
Internal projects that help other parts of the company directly, like tracking expenses, support requests, or anything in the company that takes people a lot of time and effort. This has a direct benefit.

Really this is about being brave and taking a risk. This is what happens when people become emotionally invested:

Increase in loyalty (to other people, projects, brands, employers, etc.)
Spending time on the subject.
Seeking to persuade others to also become invested.

Think it's worth it?

Get started:

Have your creatives and devs look at all the parts of the business and find a problem or inefficiency (it can be their own job)
Come up with a way to solve it
Find somebody to help
Start today (As long as today is Tuesday)