We all do it.

File, Open. Scroll down, scroll down, pause. WTF!^$%@!. Scroll up, pause. Scroll down. “Wow……, dude you have to come look at this…”

Yeah, we have all been there, finding code that we love to hate. It’s sloppy, hard to read, and looks like a monkey with no fingers pounded it out. Code so ugly only it’s mother could love.

But really who can blame software developers for hating other developers code? A large part of software development is artistry and intellectual matter. I assume that literary authors have a difficult time truly enjoying other authors’ work because either they believe it is horrible or they deeply respect it but then have a sense of jealousy.

So what can we do to find enlightenment instead of anger in these moments of discovering rotten intellectual stew?

Laugh

It is very easy to get angry, but why? The damage is already done, so let’s do something constructive.

Pretend that you wrote the code 5 years ago. Hell, maybe you are looking at your own old code – oh the irony! Whether a co-worker, past employee, or you wrote the code – take a moment to chuckle at it. Chuckle at it’s complexity, chuckle at it’s comments, but most important chuckle at fact that you once were at this point too and that is why you are now wise enough to recognize a better way of doing things.

Learn

One of the largest life lessons I could ever learned was to take every single moment, reflect on it, and attempt to learn something new.

Although there may be a dozen better technical implementations, take the opportunity to speak to the original author and try and understand what they were thinking. In my career, the most enlightening moments have been listening to the innocence of interns.

Learning goes both ways, and be sure to also teach offenders why some code is smelly. Teach the wisdom, direct the plan, and help (or review) the execution.

Leave It Better

I don’t know who started the “Campground Rule” but Uncle Bob used it in his book Clean Code:

We should leave the code cleaner than we found it – Robert Martin

Identifying and laughing at bad code helps you accept it, but only fixing it helps you find new love in it.

Similar Posts:

• Don’t Unit Test? Start Counting Your “Oh Shits!”
• The Art of Harvesting Abstraction
• Concentrated Codesqueeze: February 2008
• The Wisdom Of Insecurity
• Nobody Has A Duty To Teach

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

While in the midst of other developers, I often find myself in funny little debates about metric analysis. Which metric values determine complexity, which determine quality, and most importantly which of these values are “correct”.

A common target of these debates is Code Coverage Percentages (case in point – Is Code Coverage Really All That Useful). Some argue that 100% code coverage must be maintained, others argue that there is low ROI in maintaining that level of testing.

However in the end, regardless of metric and regardless of it’s value – what matters most is that metrics relation to your satisfaction. In other words, a metric value is only as valuable as the relational context and environment in which it is applied.

Alright, I still feel that definition is a little to wordy, so let me explain with an analogy…

It has been scientifically proven numerous times that people are happier when they are relatively wealthier than their neighbors, rather than just being wealthy. In short, a upper middle class family surrounded by middle class families is more content with their monetary status than the poorest man living on Billionare’s Avenue. Hard to imagine I know…

Metric analysis needs to be perceived in the same way. There is no “correct” value of Code Coverage Percent (nor any other metric) because it is all relative to your team and previous metric goals. For example, a team just learning to unit test might find it a great achievement to hit 70% code coverage results, a venerated team might find shame in not achieving 100%, while another team’s goals might be transfixed on ROI and call 90% “good enough”. All of these metric goals are perfectly correct in their own ways because they are directly proportional to the teams attempting to achieve them.

Just remember the fundamental reason why you started caring about the metrics in the first place, so that you can drive yourself to become healthier, wealthier, and wiser each and every day. Focus on that and before you know it you will be the richest kid on the block.

Similar Posts:

• Squeezed Links: November 2007
• The Blame Game: How Necessary Is Traceability?
• Concentrated Codesqueeze: January 2008
• Does Your Team Have STDs?
• 3 Simple Ways To Avoid Making Code Smells

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

What is the difference between intelligence and wisdom?

Some would venture to say experience, and I would agree to a point. I believe it is our failed experiences that continue forcing life’s lessons down our throats. An additional injection of humbleness through humility, and we have the perfect dose of much needed medicine to aid us in our journey towards personal improvement.

So what is stopping us from traveling down the path of enlightenment through failure? Simple. The fear of perceived failure.

Notice I did not just say “failure”, “fear”, or even “fear of failure”. What I am after is “perceived failure“, which can be interrupted into many things including:

Perceived lack of…

• Knowledge
• Artistry
• Intellect
• Ability
• Skills

You need to quit sweeping known uncertainty under the rug and this includes your code.

I grow weary of code reviews where the author (with a nice sized grin) proudly shows their clean solution, and then [being the asshole I am] call to see where they hid all of their crap code that I know is truly holding the house of cards up. Their grin quickly turns to a defensive posture, and the true code review begins…

I don’t care what you best code is – I want to see the weakest link! You and your solution are only as strong as the weakest link, so let’s take a look at it and improve it. We all have them, so let’s quit hiding them. Sure you might not look like superman now, but at least you won’t look like a liar later when your bad designs and hacks come back to haunt you (and they will).

Find it hard to open up to a group of people? Find those one or two buddies you always show your crap to. They don’t even have to work on the same team or even in the same company as you. As long as you think they can help you out, confide in them and allow yourself to take criticism.

The road to being better is to simply allow yourself to become better. Your pride is your own worst enemy in this scenario, and overcoming it will start to open many doors that lead to learning opportunities.

So after all this, why should you never flaunt your best code? Because self pride leads to a lack of humbleness…plus it’s probably not all that great to start with.

Similar Posts:

• Your Software Process Sucks : Resistance To Change
• Metrics and Wealth – It’s All Relative
• Do Managers Prey on Developer Pride?
• Why Are You Asking Me This Question?
• Geek Speak: When Developers Attack!

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

I do agree that every team must have (and enforce) some basic standards of code uniformity. These may include items such as:

• Use PascalCase over camelCasing or Hungarian notation
• Prefer language keywords over hard types (as in – int not Int32)
• No single line if statements or use of ternary operators such as ?
• All references to class member variables will be prefixed with this.

These types of standards give a clear outline of the fundamentals of code cleanliness and uniformity that can aid in a team environment.

However, often I see team leads attempting to micro-manage these coding standards. The majority of these standards have very low impact on overall readability and maintainability. I have see religious wars break out over stupid standards such as:

• { on new line or same line
• _ or m_ in front of private variables
• The order of class member declarations (private vars, ctors, props, methods [in alphabetical order], etc…)

It is unfortunate that I see teams creating standards not only littered with these types of rules, but fore-running as the core foundation. These types of standards do have worth, but must be enforced with a much lighter touch as policing these types of infractions just does not yield overall benefit to the application.

In the large scheme of things these types of code uniformity infractions are small potatoes. It is the equivalent of creating a standard way of monotone communication for optimal office efficiency – yeah ok.

I am not advocating that we should not have coding standards nor that they should not be enforced by frequent code inspections; however, I am of the belief that developers write code with minor deviations that show the same uniqueness you would see in articulated words or drawn pictures. Instead of attempting to find a happy standard, let’s celebrate our minor differences in writing code and be more adaptive to different flavors.

Sometimes the small things do matter – but not in this case.

Similar Posts:

• Best of Codesqueeze 2008
• The Dangers of Git ‘R Done
• Burning Down the Architect Title
• Whiteboard Wednesday: Keeping Teams Small
• Metrics and Wealth – It’s All Relative

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Experience is something you don’t get until just after you need it.

It is true that you can learn from books, blogs, and colleagues without impacting your current project, but wasn’t their wisdom derived from failure as well?

With technology moving at the pace that it is, will software development always be viewed as the bumbling idiot?

Lots of questions, willing to hear lots of opinions…

Similar Posts:

• The Wisdom Of Insecurity
• Comfort vs. Confidence – A Thin Line Between Apathy and Assurance
• Your New Process (Some Assembly Required)
• When Quality Service Affects Quality Software
• Don’t Flaunt Your Best Code, Show Us Your Broken Crap

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

The pupil asked the master programmer:

    “When can I stop writing tests?”

The master answered:

    “When you stop writing code.”

The pupil asked:

    “When do I stop writing code?”

The master answered:

    “When you become a manager.”

The pupil trembled and asked:

    “When do I become a manager?”

The master answered:

    “When you stop writing tests.”

The pupil rushed to write some tests.

If the code deserves to be written, it deserves to have tests.

More great zen testing lessons can be found in The Way of Testivus by Alberto Savoia



Similar Posts:

• Ye Pirates of Unit Testing
• Squeezed Links: August 2007
• Extra Squeezed Links: July 2007
• Bizzaro Development
• 3 Simple Ways To Avoid Making Code Smells

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

A recent analogy comparing software maintainability with a lobster triggered a moment of inspiration about the Gut Instinct Equation.

From the Gut Instinct Equation we know that progress is not linear. What I am now pondering is if this is because of the cost of maintenance. Even on greenfield projects this cost starts coming into play once you write one line of code. For each added feature, you must maintain the integrity of every feature you wrote before it.

Could it be that the developer on the project never realizes that the system is unmaintainable, much like a lobster in a slowly heating pot. The lobster has no idea what’s coming.

Slowly over time, much like the lobster, the team slowly finds itself grinding its wheels. Productivity has not decreased, in fact, they are probably starting to work overtime even. Costs are starting to very slowly spiral in terms of labor per feature. Bugs might be incrementally getting worse. The team, however, hasn’t noticed any drastic change in the project or the way they work. – Evan Hoff

After reading the above analogy, I became very aware that perception is not always reality. Perceived progress stays linear because ensuring previously built features don’t break is a subconscious and automatic response. However, the cost of doing feature maintenance increases with refactoring, more testing, or just the time to slow down and think.

If this is the case, TDD and unit testing becomes very important. Having the comfort of unit tests allows developers to do fearless refactoring, quicker testing, and reduces the drag time pondering if something will break.

Remember young grasshopper…you may not be a grasshopper at all…but a lobster in a pot!

Similar Posts:

• The Gut Instinct Equation
• Don’t Unit Test? Start Counting Your “Oh Shits!”
• 3 Simple Ways To Avoid Making Code Smells
• Refactorbation
• Adding People To A Late Project Makes It Later

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Imagine this, you are in a meeting with a client and they request something absurd. You respond that it is a bad idea from a technology view. Your business analyst (program manager, whatever) shoots you a look while calming the client and saying “of course we can do that feature“.

Sound familiar? If it doesn’t you haven’t been in the business long. While the last few years in the software consulting business have been great, I have had problems adapting to some of the consultant mentality.

The saying “provide a great customer experience” floats around often. I can completely agree with this; however it appears that engineers and businessmen view quality service from different perspectives.

Engineers would like to believe that a great customer experience is derived from two things: the delivered software and their professional opinions and expertise that created the software.

Businessmen view great customer experience as being as accommodating as possible. Making customers feel important and in control. This part of business should be accredited as well, it is an important part that keeps customers returning.

But here is the problem with these polar views…

Engineers may not care if the client experience is blunt, harsh, or hard-to-swallow; as long as the delivered software perfectly fits the customer’s need and is something the engineer is proud of.

On the other hand, the businessman is more interested in ensuring that the client walks away with a feeling of satisfaction over quality software, which might lead to feature creep and unrealistic promises. The perspective is that a happy customer with a piece of crap is better than a customer with great software but an unpleasant experience.

Maintaining customer relationships is like running a restaurant – you need to provide both quality service and product. If your favorite Italian restaurant is out of the lasagna, they will politely say they are out of the lasagna and give you other options – realistic and polite. They do not bluntly declare “Impossible!“, nor do they say “Sure! We will look into that…“.

When asked for a feature enhancement, most clients are asking if it can be done. If it can – accommodate. If it can’t – politely explain why not and provide some new options.


Similar Posts:

• Customer Polarizing – Why Microsoft Will Always Be A Mediocre Giant
• Quit Putting Your Solution In My Feature Request!
• Does Gaining Experience Lower Your Software Quality?
• Rearranging Furniture for an Unfocused Client
• The Dangers of Git ‘R Done

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

1. Eliminate gold plating

I looked over the artifacts for my last couple projects in order to find some insight. Habitually, I allowed 1-2 moderate to high smell hacks per project. Further investigation found these hacks were implemented during the last iterations of each respective project.

Late game hacks are not an uncommon thing; however I did find the correlation between end game gold plating and these hacks interesting. Over the past couple of years, every hack was associated with a gold plated requirement (both developer and client initiated).

The mere speak of the acronyms YAGNI and KISS should send gold plating packing. Awareness of budget and quality impacts is also great motivation for not allowing gold plating and feature creep.

2. Negotiate for time to refactor

Lots to do, with very little time. How you handle this situation will determine if you will be adding new features or new code smells.

Repeat after me:

“After the core requirements are complete, I do not have to cram all of the enhancements only using the remaining budget.”

Negotiate with the client or management to prioritize the remaining requirements. This will give you the time you need to complete as many as you can correctly.

3. Go heavy on unit testing and documentation

Push comes to shove and it is time to throw in a hack. Unit test it harder than normal, and never assume people will be able to follow the hack through code so document it more than normal. Personally, I explicitly use the notation //HACK just as much as I use //TODO.

In short, code smells and hacks are just like mother-in-laws. The best way to handle them is to just avoid them all together. If that is not possible, negotiation, documentation, and testing will make a ton of difference. Happy Coding.

Similar Posts:

• The Dangers of Git ‘R Done
• The Broken Iron Triangle Is Broken
• Concentrated Codesqueeze: July 2007
• The Gut Instinct Equation
• How Many Bedrooms Did You Say?

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Morts and younger programmers may not have the experience to walk the fine line between responsible software architecture and ‘quick hacks’. As a result, this is a very dangerous message to those developers with not enough maturity to make these decisions (but are forced out of necessity).

A number of driving factors exist why developers practice unhealthy expedient programming techniques:

• Trying to match fictitious budgets or timelines
• Attempting to pull higher profit margins off of fixed budget projects
• Fighting potential embarrassment of not finishing on-time
• Egotists attempting to over-deliver

Walking this line is tough for even veteran developers. I would argue that this is because it is an art form in mostly client communication and compromising. But I digress…let’s stay with the situation where a developer has to make a client assumption on expediency vs. maintainability. What are the top 3 questions you would ask yourself?

1. Does the client appreciate Expedience over Stability?

For example, assume we are talking about auto mechanics. Would you rather have your car fixed faster but run the risk of breaking down, or have your car fixed correctly but be in the shop longer? A small survey at where I work reveled that clients would rather have 3 working features than 5 semi-working features. This seems common sense, but many developers forced to make assumptions will choose to create more features than fix the ones they have already coded.

2. Will the solution significantly destabilize if I make a hack?

Can your application handle another hack? Has it been a fortress until now, or has it slowly turned into a card house? This is the judgment call of the developers. Unfortunately, it is often incorrectly left to the client to decide. This is where the developer needs to be honest and propose compromises.

For example, a client requests a feature that will not easily fit into your current architecture. If a hack will not destabilize anything, a hack might not hurt. If you have to refactor code just to fit the hack in, you might be in trouble. In either situation the solution is simple, lay the cards on the table and when in doubt ask the client Question 1..

3. Is the client willing to compromise on this feature?

Most clients are not married to the features that they request, instead they are passionate about the domain problems that the features solve. Proposing new features that accomplish the same task can satisfy both client and programmer.

Other compromises can be made:

• Reduced Price
• Delivery of feature in next version
• Trade some features for others

Still not sure of what to do? When in doubt, error on the side of quality and aim for perfection. Anything short of asking the above 3 questions and you are making dangerous assumptions.

Similar Posts:

• Squeezed Links: October 2007
• 3 Simple Ways To Avoid Making Code Smells
• How To Sell Agile To Fixed Bid Contract Clients
• Lobsters Attack the Gut Instinct Equation
• The Gut Instinct Equation

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.