Defining Done

Well, It’s Just an Idea

This is your starting place for building or working on something. It’s more than a dream but not quite a reality. You’ve written it down, even mapped out what you are going to build. You have a blue print of what you want to build. There are likely several diagrams and documents. This is the point that the SCRUM stories of Kanban cards get created.

It’s very rare that you would stop here. You might stop if after writing it down you realize that the tools or technology you need to build it does not exist or is not possible. In other cases you may be given incomplete information. This could be from poor or missing acceptance criteria. Lack of steps to reproduce a bug. Whatever the case, if you don’t have all the information needed then you are done before you really get started. You may perceive a need, write it out, then when taking it to the business find out they don’t need it or have other processes in place and don’t need it. A lot of times stopping here usually means that you are putting it to the side for now.

This is a starting place for your project, story, or task. You will most likely keep going from here. This is the planning phase. If you aren’t planning out your stories and tasks you need to start. It will help you know where to go and get to done quicker.

Worthy of Momma’s Fridge

“You’re proud of it, your momma’s proud of it, but that’s about it.”

You threw something together, maybe your very first attempt at a new technology or at coding a new language. You’re proud of it, your momma’s proud of it, but that’s about it. Most of us have that simple application we always build when trying something new. This is the code you write just for yourself to see you can get a thing working. It typically has hard coded values and “magic” strings all through out it. You aren’t going for elegance or efficiency here, or even cost effectiveness. This is not meant for public consumption. It’s for trying something new. Trying things out to get to a place to be refined.

There are a few instances when you’ll find it’s best to stop here. You may find out that what you want to do is too costly to build. That is too costly to do it correctly, or at scale. It’s important to recognize this because the cost can sneak up on you if you don’t recognize this early. It may not become evident that something isn’t possible until you have started working on it. Another time to stop here is when building something as a learning experiment. You may be learning a new technique or language for part of a project. There’s no need to continue on refining once you learn the technology and can apply it. Finally, when writing code for textbooks or StackOverflow this is the ideal place to stop.

This is another place you will rarely stop or be done. It is a step on the way to being done. For more difficult tasks this is the poorly written code that gets the task done but needs to be refined.

Proof of Concept

A proof of concept is a pilot project or experiment that shows an idea is possible and feasible. It’s a bit more refined that what you’d put on your momma’s fridge. This is the code you write to show other people that a thing is possible. It’s not written for publication or external use other than to show customers what can be done.

Since this is for showing the business side something is possible they tend to be the cause of stopping here. You may be waiting on a business decision on how to proceed. This could be they want to go but have higher priorities to finish first. There may be some time for market research to determine how best to refine what you’ve built.

The business or the team may not like the concept. It’s very frustrating to work hard on something only for the idea to be turned down. This is why you don’t go too far before showing a POC. The business could like the concept but still want to go in a different direction.

Once you get the go ahead, then you keep moving from your POC. Never stop when management wants to publish your POC in production. Now that you’ve proven it can be done it’s time to build it to be maintainable and scalable.

Code It To Completion

This is your first iteration of something that is production ready. You’ve got it completed. All of the requirements are met, it is coded to do everything that is required. It may not be the best, most maintainable, or most scalable code but it is decent. You’ve moved your hard coded values into variables and configs. You’ve run it a couple times to make sure it’s working.

There are a few times when it is wise to stop here. If it is a small fix, or small project with little expected traffic. If it is internal and doesn’t need much refining. This would be something like a viewer for looking at API logs in the database. The only people looking at it are IT, not even internal customers. If there are severe time constraints. In this case it may not be fully done, but enough to get it out the door. Then further refining can be done on it.

In most cases, though, you are not going to want to stop here. It’s very likely that QA finds bugs or errors in what you’ve written. If it is going to be a major part of business or an app you’ll want to keep testing and refining so that your changes don’t break the application and cause loss of business. At whatever level, be it project, story, or task, it will need to be refactored or refined before being released into the wild.

Good Enough For Government Work

You’ve gone above and beyond your first iteration and done some testing and refining at this point. You’ve unit tested the happy paths but not so much the unhappy ones. You know it does what it’s supposed to do. You may have expectations on how it will handle errors. When all is going well, under light load, your app rocks! What it does when something unexpected happens in anybody’s guess.

“It’s great if you work for the government…not really.”

This is considered a good stopping point for many developers. A lot of developers feel as though this is enough testing and refining. Once they know it works, it’s good to go. They either don’t think about unhappy paths or figure that’s QA’s job to find. If it’s a small application or task that you know you will have full control over the input. You know that no one will ever touch this area of the codebase again. This is a small patch in a very seldom used area of the code.

Like a false start in racing, this is usually the false stopping point that gets many people. If there is any chance this code will ever be touched by another process or developer, you need to keep testing and refining. Testing only the happy path, is not being thorough in your job as a developer. You need to plan for and test for as many possibilities that you can think of a user doing, then expect them to do something new.

Refined, But Not Quite Emily Post Refined

You’ve unit tested the snot out of what you’ve built. Both the happy and all conceivable unhappy paths are tested. The code may even have some error handling in place for unexpected outages or inputs. You haven’t really thought about optimizing the code except where obvious.

For many this is a good place to consider a task or project completed. Stop here when you need to balance doing things right with time constraints. Typically developers who stop here know they could do more but have to move on to other tasks. They may want to do more but are pushed by management to move on. Management will also think of this as a good place to stop.

If you are going to write the best possible code you don’t want to stop yet. Refactoring is a constant process so you should always be refining your code when you are in it. As you grow as a coder you’ll learn better, more efficient ways of doing things. You’ll want to update your existing code to meet these better standards. That also means updating your testing.

Emily Post Refined or Making Uncle Bob Proud

Your code could be textbook, except it works and doesn’t leak memory. The code is unit tested, load tested, and integration tested with other systems. You are using proper design patterns or have refactored to use them. Best practices and accepted standards, either industry or company have been implemented.

This is the ideal place to consider yourself done. Doing much more and you run the risk of over-complicating or even breaking your code. You don’t want to get so obsessed with meta programming that you turn your codebase into pattern soup. You’ve got a good balance here, time to let this baby fly.

There are a few scenarios where you would want to keep going. If what you are building is extremely complex and needs more refining and testing. You can never be too careful if it’s a system that will affect whether people live or die. Financial systems can be just as complex and needing of extra care in the development phase.

Less drastic but important is when it doesn’t meet business needs. There’s little more frustrating than spending a lot of effort on a task or project only to find out that while you coded it to do exactly as they asked, it’s not what the business needs. Poor criteria can destroy even the best written code.

It’s Not Over Until QA is Tired

This is going above and beyond, not because you want to do that. It may be that QA thinks they are the ones making the business decisions. They will send back bugs that are more matters of opinion. It is likely not out of malice but a misunderstanding of their job duties. There could be differences in interpreting the acceptance criteria and what is needed. Then again, it could be extremely complicated or important and they are being overly thorough in testing.

At this point you wish you could stop. Start by talking to your QA about the items that are not bugs. Get management involved if it doesn’t cease. It may take sitting down with management and the business/customer to clarify what they want.

QA is not always in the wrong here. You are not done if lots of bugs are still found in your code. They may have a better understanding of the business process than you. When calling them out on it, you need to consider that they may be right on what the business wants. If that is the case then you’re not done and need to adjust to the needs of the business.

The Never-Ending Story

It just never ends, you’ve been working on this project for months/years. An idea becomes a passion; a passion becomes an obsession. You’re tinkering with something and just keep going with it to the detriment of other things.

You probably should have stopped a while back. It’s easy to get into the weeds when developing. You lose track and end up spending all day on one little used area of the code. Sometimes you will find yourself trying to solve a problem in an overly complex manner. This is something mid-level developers have to especially watch for in their code. There is a tendency to over complicate as we learn to write more complex patterns and syntax. Senior developers aren’t immune to it, they just typically don’t have the excitement about the complex and only use it when necessary. You may find yourself over optimizing to the point your are spending hours of development time in order to save seconds of processing per year. At this point optimization becomes an anti-pattern.

It’s very rare that you would want to continue here. Maybe if you want to torture yourself or your mentor with too many math functions. You are working on a fun project or educational project and trying to hammer in a concept.