Using Gamification to Motivate Development Teams

In this post I'll share some gamification techniques I've used to motivate software developers and improve team performance. For those not familiar with the term, gamification means using some elements of games in a non-game setting, such as developing any kind of software. It's all about adding some fun elements to the work that engage the team to rally around some activity and excel at it.

If you doubt that games are a big deal these days, just consider the statistics. According to Filmora, Over $115 billion was spent on gaming in 2018. While gaming is often associated with the young, 63% of gamers are 21-50 and 15% are 51-65. 46% of gamers are women. Some people earn their living by streaming their video game play, called esports. Last year, for the first time the Winter Olympics included an esports event, and some expect esports to become a medal event by 2024.

Why Gamification in Software Development?

Gamification techniques can, in theory, be employed anywhere there's a human endeavor—but it certainly helps if what you're doing already contains elements that lend themselves to gaming. Software development happens to be a great fit.

Gamification is all about motivation, and fun is a huge motivator. In software, like anything else, there are tasks that are naturally fun and other tasks that aren't so much fun. For example, most developers like working on features but dislike bug fixing. Features are fun, bugs aren't. What gamification can do is lend elements of fun and competition to those tasks that aren't already fun.

Managing a team of software developers can be like herding cats at times when what you need is everyone pulling in the same direction and pulling their weight. A good development manager is concerned with both team delivery as well as the care and feeding of team members. He or she will want to see their team reach a point of low friction and high performance, which requires working well together. It's in this area, team dynamics, that a software manager can employee gamification techniques to promote and improve cohesive team behavior. Some of these techniques are subtle but they can make a difference.

Software development is certainly a race to the finish, and I know of no better illustration than the classic 1959 film Ben Hur starring Charlton Heston. If you're familiar with the film, you might recall the scene where Judah Ben Hur first meets the Sheik and his four white horses, to whom he is very much devoted. Ben Hur observes the team racing and casually observes that the horses each have varying strengths, and the team would function better if certain changes were made such as moving a different horse to the inside of the track. The sheik is impressed with Ben Hur's prowess in team dynamics and pleads with him, "Can you make my four run as one?" Ben Hur agrees to work with the team, which goes on to see great victory.

In Ben Hur, "four run as one"

And so, a software project can be treated as a race; and an optimization task can be treated like a strategy game; and a difficult bug can be treated like a puzzle. There are many opportunites to apply gamification in software development. Let's look at a few examples.

Using Dashboards for Fun and Effective Metrics

Dashboards are fertile ground for gamification. Since many games display scores or stats, you can visualize software development metrics in the same way. Take bug counts, for example. You can show active open bug counts prominently. Even better, you can color-code them based on count, priority, severity, or whatever you choose to emphasize.

Showing Bug Counts wth Color Coding

In addition to raw bug counts I've found it useful to track how a team is trending on bugs, using the count new bugs found this week against the count of bugs closed this week. It's the ratio I'm interested in: if more bugs were found than were fixed, we're drowning (trending in a poor direction). If we're fixing more bugs than are being found, we're trending positively and our situation is improving. And if we're about even on these counts, we're just treading water but aren't really making progess. You can visualize these valuable statistics easily on a dashboard.

Bug Trend Count

If your dashboard allows it, the bug trend ratio could also be shown visually in other ways, like a seesaw or the artificial horizon found an airplane cockpits. The idea is to convey the team's direction dramatically (but not over-dramatically; everything can't be an emergency). And of course you can look at trends over time in charts and reports; here though we're thinkng about simple at-a-glance visuals the team can see every day about the current work. Whatever you choose to show, strive for clear measurements and a simple presentation: everyone should have a common understanding of what they're looking at and what they can do change the situation.

Putting scores and stats in front of the team is more than an attempt to make metrics fun and playful: it provides a feedback loop by which the team gets regularly reinforced about how effective or ineffective their efforts are. One of the most important things to learn about software teams is never mistake motion for progress. Useful visuals can help everyone on the team see that.

Making it Personal: Leaderboards

Another valuable gamification technique that also leverages dashboards is the use of leaderboards. I once worked with a team that was doing well on assigned feature work but dragged their heels on bug resolution; the bug backlog was larger than anyone liked and we weren't making sufficient progress against it, despite my weekly exhortations. It's somewhat natural for developers to prefer feature work to bug fixing, as the former is fun and the latter isn't. As a manager, I needed to ensure my team was fixing an appropriate number of bugs each week.

After some analysis of bug fixing activity, it was clear that we had a mixed bag in terms of developer focus on bugs. A few individuals were in fact addressing an acceptable number of bugs each week. Others did some bug fixes but not nearly the quota I'd established. And there were a handful who fixed no bugs at all. Even though a few were doing their part and more on bug fixes, the overall bug fix counts were far short of our goals. What was needed was a way to motivate every developer to do their part.

I hit upon the idea of showing bugs fixed each week, by developer, in the form of a leaderboard. Now it was crystal clear to the entire team at our meetings how many bugs each developer had fixed that week, ranked top to bottom by most bugs resolved. Something happens to you when you see your name displayed on a leaderboard like this: nobody wants to be on the bottom of the list, and the more ambitious will compete to be first on the list.

Bug Fix Leaderboard

Showing the bug fix leaderboard every day made a dramatic difference in bug activity and nearly all developers showed improved frequency right away. Like a sporting event, there were those clustered regularly near the top, middle, or back of the pack. When a dev, determined to break ahead, fixed a record number of bugs and rose on the leaderboard, that fact was pointed out and celebrated. Leaderboards probably aren't a good idea with a really small team but when you have half a dozen or more people they can be quite effective.

When employing gamification, you do need to be careful about the behavior you're encouraging and think about ways it might be abused. For example, a dev could rack up a large bug fix count by focusing on easy bugs of lower priority rather than top priority issues. Another way a system like this could be abused is the poor bug fix, where a dev appears to have resolved many bugs (looking good on the leaderboard) but in fact most of them end up getting reopened because they weren't fully fixed (or even worse, had side effects causing new bugs to be opened). A better metric would be truly closed bugs where the fix has been verified. You'll want to think through what you're visualizing and make sure it doesn't promote unintended behaviors.

Badges and Microcredentials

Years back, when I was a practice manager at Neudesic, I needed to train as many of my consultants as possible in a new area: cloud computing. Microsoft had a Virtual Technology Specialist position that partners like Neudesic could participate in, and when one of my consultants qualified I awarded them one of these physical badges. It's not that they actually wore these when going to clients, but these badges of recognition were something they could proudly display in their cubicle, and they incented others to have similar aspirations.

Today we have social media, and you can do the same thing digitally. If you use enterprise social media in your organization, and there is support for badges, then you can award badges to team members for good performance. Badges are a form of digital recognition; they're a way of patting someone on the back, figuratively, in full view of your organization. You can have a variety of badges that recognize such things as Excellence, Above the Call of Duty, Innovation, Grace under Pressure, Burning the Candle at Both Ends, Road Warrior, and so on.

Awarding a badge may seem minor compared to something more substantial like a good performance review or a raise, but they have the important benefit of being immediate and being widely witnessed by others. At my last place of work, I felt really honored when someone in the company awarded me a badge, and I know others felt the same when I awarded them one. It's a simple, easy thing to do; and they work.

Badges in Social Media

Badges can be used another way besides in-the-moment recognition; they can be used for microcredentials. A microcredential recognizes an achievement or status that a team member has reached. For example, someone who has shown significant innovation could receive the Innovator micro-credential. Whether the requirements for that are a single innovation or repeated innovation is something for the team/company to decide.

Whereas the aforementioned use of badges is mostly a matter of "someone catching you doing something right", microcredentials usually take some effort to attain. A badge is similar to a like, whereas a microcredential is more like unlocking a game achievement. You could use microcredentials for all sorts of things in a software team, for example Build Master, Dev Ops, Certified Expert, Master Debugger, or Published.

Example of Micro-Credentials

With badges and microcredentials, you want to avoid making things too easy: if everyone gets a "participation award", the value of the award is diminished and so is team motivation.

Puzzle Solving

Puzzle solving is a common task in software development that also lends itself to gamification. Whether it's finding the best approach in your design, optimizing an implementation, or diagnosing a bug, those puzzle-solving tasks become a bit more fun if treated like a game.

Another favorite film of mine is Apollo 13. There's a scene in that movie where the astronauts are running out of breathable air because three men are trying to survive in a lunar module intended for two people. Engineering is tasked with finding a way to make the square air scrubber cartridges from the command module work in the lunar module which used round cartridges; effectively, a square peg had to be made to fit in a round hole. Moreover, the team could only use the items the astronauts had available to them on board.

Apollo 13: "The people upstairs handed us this one and we gotta come through."

What I just described was crucial work that if not addressed would have meant the death of three people. But the work can still be formulated as a fun puzzle and I'm sure the engineers took delight in the solution, which involved duct tape, part of a space suit, and cardboard.

Prizes

For big engineering challenges that are above and beyond normal work requirements, consider prizes. That might take the form of throwing out a challenge across the company and choosing a winner out of the submissions. Doing this allows more people to get involved than assigning the problem to a single team and you get more fresh ideas that way. Innovation just might come from a surprise corner of your organization.

Offering prizes for solving engineering problems is not new. Charles Lindbergh flew solo from New York to Paris to win the $25,000 Orteig prize in 1927. More recently, the XPrize foundation has been rewarding innovators in private space exploration. Rewards can work just as well on a smaller scale within an organization.

Frequent Demos and Feedback

I encourage my teams to do frequent show-and-tell. Even if we're doing Agile Scrum, which is supposed to end with a demo at the Sprint Review, I like to see demos regularly—at least once a week. My selfish reason for this as a manager is to have an opportunity to give feedback and provide any needed course control. However there's also a gamification aspect to frequent demos: having developers regularly show off their work is a form of competition.

I know that I work better and get more done when I am encouraged along the way with constructive feedback. Note that I said constructive feedback, not undeserved praise. Regular demos are a great way to encourage mutual constructive feedback. It's not only enjoyable, it results in better software. Whether demos are an official part of your software methodology or not, I'm a big believer in them.

If your workplace has any notion of setting aside weekly time for developers to play around on their own projects (the idea behind Google's "20% projects"), that's also a great thing to publicize with demos to the team. It gives recognition, the group feedback is invaluable, and it subtly reinforces competition across the team which raises the bar across the board.

Mundane Tasks

Every once in a while I find I have to do something that is very, very mundane and repetitive. It might be promoting a bunch of tasks to another sprint, one at a time. It might be that a long list of statements or data elements in a code editor all need to be massaged in some way.

Sometimes tasks like this lend themselves to automation and sometimes they do not. At times I catch myself and say, Wait! I can write a small program or script and save myself a lot of time. And that's great. But when I can't do that, it's back to the onerous, seemingly never-ending repeated task. I used to just power through such tasks, but more recently I've found ways to make even this kind of work somewhat fun. When I'm in the moment of doing tedious-but-necessary repeated tasks, I can sometimes treat them as a game. What combination of keystrokes or clicks in the editor updates the next statement with the fewest number of interactions? What combinaton of keystrokes is most balanced across the keyboard? Gamification can be applied in many places if you look for it and are sufficiently motivated. It's a form of "Whistle whle you work."

Can Gamification Backfire?

One potential result of gamification is that your team will play the game. The Hawthorne Effect is a phenomenon in which participants alter their behavior as a result of being observed. That is actually what you intend: you're encouraging your team to engage in order to "win"; the gamification's goal is motivation, engagement, competition, and a change in behavior or performance.

However, it's also possible participants will try to win in less honorable ways by gaming the system itself. Consider our earlier example of leaderboards for bug fixes, where the most bugs fixed each week gets you to the top of the leaderboard and the bottom is a place of shame. In addition to the potential abuses already mentioned, anyone with project experience knows that one bug can often be logged as multiple bugs and vice-versa. That means these kind of metrics are susceptible to manipulation when there is bias. When setting up gamification, you'll want to think through potential abuses beforehand and take measures to thwart them; no one enjoys a rigged game. In the case of bug tracking, you might lay down some specific rules about how bugs are to be logged, avoiding duplication, and what the criteria is for claiming they are fixed... before you introduce a leaderboard.

Conclusion

Making work fun leads to happier workers and a better work product. In software development there are multiple opportunities to apply elements of gaming in the course of project work. Today we've examined a few from my own experience.

If you've never tried gamification, give it a whirl. You might be surprised how effective it is to inject a little fun at work. By the way, there's no need to inform a team you're employing gamification techniques; just start to use them and observe the changes in behavior.

Debugging Azure Cloud Applications

At some point you will need to debug your Azure cloud applications. Here is some guidance on what the options are.

Local Debugging. First off, the general hope is that you'll catch and fix problems on your local box long before you place anything into the cloud. Locally you can use familiar tools such as the Visual Studio debugger and event logs and other tools to get to the root of problems.

Application Logs. However, it's possible to have an app that works locally that doesn't work when deployed to the cloud. What do you do then? You look at the logs for your application, that's what you do. Unfortunately this is something of an involved process today:

1. You have to first find the Copy Logs button, which is lurking under your Configure button on the Azure portal. This hasn't been obvious to everybody.
2. Clicking Copy Logs will copy your logs to your storage account.
3. Lastly you need to run a program to read your logs out of cloud storage so you can view them. There is a sample in the Azure SDK called CloudDrive that does this. It is an exension to PowerShell. There is some work involved to configure, build it, and get it going the first time around.

No doubt this will become more streamlined over time, but it's what we have to work with today. Benjamin Day has written an excellent post that gives a blow-by-blow account of exactly what you need to do, including screen captures. You can also instrument your application to write to those logs using the RoleManager.WriteToLog method.

MSDN Forums. MSDN has a very good set of forums set up with several Azure categories. I've mostly been interacting with the Windows Azure forum, and I've found it to be a great place to go to get answers or help others. Moreover, Microsoft personnel have been fantastically responsive and helpful. So if the above methods don't help, post your problem to the appropriate forum. Between Microsoft and the community you'll likely get some help.

The Less is More Revolution

The Less is More Revolution
By David Pallmann, Director, Custom Application Development, Neudesic

I'm making it official and declaring that we are now in the midst of a major revolution in computing, perhaps with overtones that extend beyond technology. I'm calling it The "Less is More" Revolution. It amounts to a major refactoring of how we do things, ...of how we do everything.

When I say "Less is More", you probably think instantly of Apple, one of the great success stories in applying less is more as a design principle to hardware and software. If you're not a proponent of less is more, spending 10 minutes with an iPhone or an iPod will likely make a believer out of you.

But "Less is More" didn't start with Apple, nor does it end there. The phrase has actually been around since the 19th century. One of the founders of modern architecture who used the phrase often and believed deeply in simplicity of style was Mies Van Der Rohe, who dabbled in both architecture and furniture design. So less is more isn't new, but it is coming into full bloom.

"Less is More" certainly makes sense as a UI approach. The 80/20 rule frequently applies: you may find you can provide the important 80% of possible functionality with a mere 20% of the UI that you would need to cover everything. Not that this comes easily or automatically. It's not hard to make a simple interface that does simple things, nor is it particularly hard to make a detailed interface that does many things--but who wants to use either? What takes work and validation and refinement is finding the sweet spot where a simple and pleasing UI yields the most power for the user. That outcome is worth the extra effort it takes to get there.

Social networking web sites such as Facebook also demonstrate less is more. I and just about everyone else I know are on Facebook or similar sites constantly, and the primary activity is to update our "what are you doing right now?" status and view the status of others. From a computer science perspective, this is not exactly rocket science. From a social perspective, it's huge: I actually feel closer to friends and family today, many of whom are thousands of miles away, than ever. I feel more a part of their lives. It's a little thing with big implications. It's less is more.

The Agile Manifesto and accompanying interpretations are a good example of less is more in software development methodology. By focusing on what's important and reducing emphasis on the less important, you measurably accomplish more by doing less. In other words, less is more can be applied to process. This has great implications for improving business process itself as well as the technologies that support business process such as workflow engines.

"Less is More" has been popping up as a principle in web technologies as well. The influence of REST, an approach to simplifying the way data and resources are exposed on the web, is phenomenal. When I worked at Microsoft during the time when WCF was being developed, I don't think I heard the term "REST" once. Today, not only can WCF do REST, support for REST seems to permeate just about everything Microsoft is doing. Don't believe me? Search MSDN for "REST" and you'll get close to 500,000 hits.

"Less is More" and REST are both utterly pervasive in Windows Azure, Microsoft's cloud computing platform. Just about anything you could want to do with the cloud computing platform can be invoked or accessed as an HTTP REST URL. That includes database storage and queries with SQL Services. At the recent PDC convention in LA, Don Box and Chris Anderson showed the attendees just how much they could accomplish using just REST and simple web HTTP requests. You can watch the video here.

In the cloud computing case, the "Less is More" effect is quite pronounced. As Microsoft extends its enterprise platform into the cloud, with new capabilities and new business models, you might well expect increased complexity in designing, implementing, and deploying software. Instead, there's less work involved. Things are just a lot simpler to get at and work with and combine and deploy, thanks to some great design decisions. I do have to admit "less" also rings true in another sense: there is less functionality available to you. Because the platform is so young, there are lots of things you give up. The cloud offerings aren't anywhere close to what the enterprise technologies give you, today, but they do give you the most important things. I'll readily admit SQL Services in the cloud appears to give me only a fraction of the functionality of SQL Server in the Enterprise in its present form. Of course that will change over time. The interesting point is, it doesn't matter. I'm going to happily use it anyway, because the "more" the platform gives me more than makes up for the "less": the way the platform is put together is so radically empowering that it's worth it to put up with functional omissions.

I'm thinking less is more is now a firmly entrenched and warmly embraced concept in the minds and hearts of consumers, meaning there's going to be more and more demand for it in everything from web applications to kitchen appliances. A growing portion of the public knows the difference between overengineering and elegant design now from firsthand experience, and everything I'm observing indicates people will flock to refreshing alternatives in droves at every opportunity--even when there's some additional cost involved.

"Less is more" is sometimes defined as "minimalism", but I'm not sure I like that word as it suggests "doing without" or some sort of monastic asceticism. When less is more is done well, you don't feel like you've given up anything. Rather, you feel highly empowered and effective. When you encounter less is more engineering in your daily life on a regular basis, the sun shines a little bit brighter, the sky is bluer, and the birds are singing more loudly and cheerfully than ever. It's a good thing, and when you enter that zone you don't ever want to leave it.

Is less is more a discipline for designers, or is it a something to be mastered by every developer? I say it needs to be both. We clearly won't get less is more pervasively unless designers lead the way with this as a foremost principle, but less is more extends far beyond design, as we've already illustrated. Developers need to practice less is more every time they create a class, implement a function, or design an interface. Remember, less does not automatically lead to more: that result is never an accident. Rather, it's a by-product of conscious intent. For this reason, all developers need a firm understanding of the principle. Fortunately, excellent groundwork has been laid by Martin Fowler and others in advocating refactoring. Less is more fits in with refactoring quite nicely.

What makes me think I'm right about this? These influences have been going on for some time, but my recent foray into Cloud Computing with Microsoft's Windows Azure platform is what brought it all into sharp focus. Exposure to elegance is contagious and addictive. Try it, you'll like it.

Are You Over-Engineering?

“Over-engineered.” Most software developers would cringe to hear their work described in this way. Yet over-engineering is common. One reason for that is, it’s easier to spot in someone else than in ourselves. To gain insights into what over-engineering is, we’re going to study what’s happened to the potato peeler over time. Below you see the traditional potato peeler that has served American households well for nearly a century. If anyone in your household cooks, there’s a good chance you have one of these in your kitchen.

There have been some incremental improvements along the way (nicer handles, angled blades) but the basic design hasn’t changed much.

The traditional potato peeler has a lot going for it. You can get the one above for about $2. It has only two moving parts, is compact, stores easily, usage is intuitive, and they last for decades.

Those design characteristics would seem hard to improve upon, but that hasn’t stopped companies from trying.

Enter the Rotato, shown below. To peel a potato (or some other fruit or vegetable), you mount it on the Rotato’s spiked base and lower the top arm. You then turn the crank and Presto! the peel comes off in one continuous strip. There is also the Rotato Express, an electric model.

Reviewers agree that when this works according to plan, the experience is fast and fun, and the potato is well-peeled. Reviewers also agree that the device does not always work well.

1. Unnecessary Complexity
At first glance, we can see the Rotato has many moving parts. While complexity is not an automatic indication of over-engineer-ing, it is one of the warning signs to pay attention to. When you see complexity that is unnecessary to do the job at hand, you have over-engineering.

Over-engineered designs are often unnecessarily complex.

2. Comparison Aids Design Assessment
To prove something is over-engineered you have to show a simpler and better design exists. Having another design to compare against reveals a great deal. We learn a lot about the Rotato when we compare it to the traditional potato peeler. The Rotato is a lot bigger, has many moving parts, costs ten times more, takes up a fair amount of space, and often lasts less than a year.

Over-engineering is best proven by comparison to a superior design.

3. Fatal Flaws Really Are Fatal
Design flaws come in two flavors, fatal and questionable. Fatal design flaws are not acceptable under any circumstances.

Does the Rotato have any fatal design flaws? Here’s one: the Rotato doesn’t peel the whole potato; in fact, it comes with a paring knife that you need for the top and bottom of the potato, and for “problem areas” of irregularly shaped potatoes.

Also hard to overlook is that the Rotato stopped working for many reviewers after they had peeled only 3 potatoes, requiring them to replace the blades.

Fatal design flaws cannot be compensated for by other aspects of the design.

4. Weighing Negatives against Positives
What about design negatives that aren’t fatal? A negative might turn out to be acceptable if there is a related benefit that is compelling, such as unparalleled safety, longevity, or an appealing feature. Or it might not. The negatives have to be weighed against the positives.

We identified some negatives about the Rotato earlier, but what are its positives? The Rotato peels potatoes much faster than a traditional peeler and doesn’t get your hands dirty. In the case of Rotato Express, there’s no manual labor involved in the peeling since an electric motor does the work. The experience is also said to be fun; this is a new benefit (you never hear traditional potato peeling called fun).

How do the positives weigh against the negatives? As you might guess, you’ll get different opinions from different people. Some reviewers love the Rotato while some hate it. Many of the favorable reviewers openly admit the Rotato’s problems yet love it nevertheless and recommend it to others. Many are on their second unit. The positives seem to outweigh the negatives for many users.

Perceived design negatives need to be weighed against positives.

5. Bells and Whistles Nobody Ordered
Another type of over-engineering is to festoon what you’re building with all sorts of interesting features that nobody asked for and nobody is likely to need. In soft-ware, this is often justified as anticipating future events or future needs.

The Rotato doesn’t have this particular problem, but a $2,320 peeler from Hobart might qualify. It comes with a stainless steel cabinet, a wheeled floor stand, leveling legs, a timer, and a peel basket.

Even if you know there will a future need for something, that doesn’t necessarily justify building it now. It’s much more important to focus on present requirements.

A design with unnecessary, unrequested features is over-engineered. Don’t design too far into the future.

6. Suitability is in the Eye of the Beholder
In reading reviews of the Rotato, it was interesting to notice that some of the most positive ones came from people with arthritis, or had limited use of their arms, or who had lost an arm. For them, the Rotato was the only way they could get back into the kitchen. We might rate the Rotato generally over-engineered, but for these people it is a godsend.

An over-engineered solution may be justifiable if it offers something crucial other designs do not.

7. Lack of Refinement and Refactoring
Over-engineering is a normal by-product of the software development process, which is why we now recognize the importance of refactoring. You often can’t see the ideal design until you’ve first achieved some prototype that works. The important thing is to not stop there. Now it’s time for iterative refactoring and design review.

Despite its problems, the Rotato has many loyal fans. It may be a diamond in the rough, a design not yet sufficiently refined.

Failure to refine and refactor often leaves an over-engineered result.

8. Trade-Offs
Design always includes trade-offs. In soft-ware, many of these trade-offs are well known. Security is at odds with performance. Database normalization is at odds with simplicity of queries. And so on.

Sometimes, people fool themselves into believing they don’t have to make any trade-offs. They reason, if we make this the best we can in every area, if we spare no expense, we don’t have to make any trade-offs. These people are wrong. The resulting complex design will bring consequences with it such as high cost, high maintenance requirements, fragility, or other risks. Luxury cars are a good example.

A design without trade-offs is almost certainly over-engineered.

9. Elegance
A sure sign of good design is elegance: over-engineered solutions are completely lacking in it. This is the place where technology meets art. Michelangelo said, “to sculpt, take a block of marble, and take away what doesn’t need to be there.”

All human beings recognize elegance when they see it. In music, not everyone is a composer but we all know good music when we hear it. The craze over iPods and iPhones is driven by design elegance.

Which is more elegant, the space station envisioned in 2001: A Space Odyssey (left) or the actual International Space Station (right)? Kind of like comparing the Sistine Chapel to an oil refinery, isn’t it?

Good designs are elegant, poor designs aren’t.

Final thoughts
An over-engineered solution is a job half done. As master craftsmen of our trade, we owe it to our customers and ourselves to make it all the way to the finish line.

While researching for this article, I explored what others had to say online and came across a blog posting using the potato peeler and the Rotato as an example of over-engineering. I thought this was a brilliant illustration--but I also felt the short blog posting did not really do the subject justice. That's my justification for borrowing the same example and giving it a fullter treatment. Unfortunately, I can't find the original posting to give proper credit for the idea.