Proper Prior Planning Prevents Piss Poor Production

As a Software (Engineer/Developer/Craftsman) it is very important to plan before you develop! As a developer you are responsible for the quality of your code.

Your code must deliver two different products:

• Working Feature or Application
• Well constructed, easy to understand source code

This means that developers build and write at the sametime. (Can you chew gum and walk at the sametime?)

This is very unique and very difficult to do. That’s why we practice as relentless as any profession. It takes dedication and determination to excel, more than any other profession I can think of.

Most developers tend just to focus on the execution of the application and sometimes in a state of reckless abandon. (Cowboy Style) No Plan, just pick the first solution and sling out some code just to get it to work.

For Example:

Johnny slings his code in a rush and pushes it to testing and calls it a day.

The testing team passes a couple of use cases, but find some problems with other cases of the code. They flag the feature as not accepted, and the feature gets routed to another developer, “Greg”. Greg takes the ticket and tries to correct the problems.

Greg is unable to understand the code and re-writes the feature based on his style and pushes it to testing, with their particular edge case corrected.

The testing team, just validates that edge case and ships the code.

The next day “Jane” a user is all excited about the new feature she requested and goes to use it with real data. She immediately enters one item, and it causes a bug so severe; it prevents Jane and others from completing other tasks in the system.

Now, all the developers are in a reactive mode to try to figure out what happened. Everyone must stop and determine how could these issues occur, and they review the code, but it is very hard to understand, they look at the trail and find that “Greg” made some changes and rush to Greg’s desk.

Greg is the only one that can fix this problem, because he is the only one that understands what he did, but he does need to consult with Johnny, since Johnny wrote the first solution. Several weeks have passed since both Greg and Johnny worked on this solution and they have slung and hacked other code that this code does not trigger any kind of memory of the feature or the solution. Under the pressure to deploy a fix, they add a big roll of software duck tape code to patch and push out.

(DUCK TAPE can FIX ANTHING)

Doing the same stuff over and over is INSANE

Imagine this pattern continues over and over for several years. Your application code base becomes completely useless. It takes an army to maintain, every release breaks more than it fixes and everyone is miserable. (Executives, Developers, Users, etc)

What is the Solution?

There are a lot of Methodologies trying to solve this problem or similar problems. These Methodologies are great and they do provide a lot of help. But the bottom line is that the buck stops with the developer and the developer has to dig deep to try to be the best they can be.

Only You can Prevent Poor Code!

Care about your work!

(If a developer or developer(s) spent 2 hours planning they code before they started writing on any small task, it could save weeks in bugs and re-writes.) I have seen this time and time again. Why do most software products really become viable at Version 3?

• Version 1 - No One has a clue!
• Version 2 - ReWrite Version 1 to be more maintainable!
• Version 3 - Create a Version that users want and is maintainable!

This is Unacceptable! Developers need to do better!

Take pride in your work! Show it off to the WORLD!

Practice every moment, go to the driving range of code and tee it up!

Learn from the Best! There are so many screencasts, podcasts, talks,

and Books!

Mess with the Best and Die with the Rest!!!!

All developers should care about their craft to want to be the best of the best, not just to put food on the table. Think about each task you are assigned, plan it out, document the plan in some form. Behavior Driven Development or Test Driven Development work great. But just writting out a readme explaining how it is going to work, or how the user will use it. Doing a screencast, creating a presentation. There is just no excuse.

NO MORE CUT AND PASTE!

So before you just start hacking away at some project and picking the first solution that comes to mind, and don’t give a crap how you structure your code, or what you call your objects. STOP!

Write a plan, or write out how you are going to tackle the problem, write out how your users will use your solution. Or just wake up and start to understand:

• Extreme Programming
• Agile
• Behavior Driven Development
• Test Driven Development
• Clean Code
• SOLID Principles

Not because they are cool, not because everyone is doing it, but because you want to be the best Software Developer on the PLANET!

THERE IS NO EXCUSE!