refactoring yourself as a developer

© COPYRIGHT 2010 SAPIENT CORPORATION | CONFIDENTIAL

Ryan Taylor | Cocoa Camp | September 25, 2010

Refactoring Yourself As A Developer

© COPYRIGHT 2010 SAPIENT CORPORATION

改善 Kaizen

Japanese philosophyFocus upon continuously making small improvements

Change (kai) to become good (zen).

High-level cycle:Identify and eliminate waste and inefficiency

Clean up and reorganize after the changes

Standardize the resulting improvements


Self Relevance


“ An investment in knowledge always pays the best interest.”

– Benjamin Franklin


Grow Your Knowledge Portfolio

Our knowledge of current technology is an expiring asset

Be diverse, don't limit yourself to one technology

When the willingness to learn and evolve ends, so does your career


Set Personal and Career Goals

Setting yearly goals is a healthy practice

Challenge yourself to:Earn a promotionReach a financial landmarkContribute to a bookSpeak at a conferenceLearn a new technology


“ Any fool can write code that a computer can understand. Good programmers

write code that humans can understand.”

– Martin Fowler


Be Passionate About Your Craft

Software development is both an art and an engineering discipline

Technology will change, but craftsmanship is timeless


Be Passionate About Your Craft

Take pride in your codeAlways seek to improve your architecturePush for self-documenting, well commented codeMaintain consistency and readabilitySign your work

Challenge yourself on new projects

Mentor your peers


Are you a better developer now than you

were six months ago?


Software Maintenance


“Everything should be made as simple as possible, but not simpler.”

– Albert Einstein


Keeping Things Simple

Complexity is easy to achieve

Keeping a design simple can be surprisingly difficult

Only design for "real" requirementsNever add functionality before it is scheduledOnly 10% of the extra stuff will ever get used, so you are wasting 90% of your time


Managing Software Entropy

Software EntropyDefines the measure of disorder in software systems

A few laws have been suggested:A computer program that is used will be modifiedWhen a program is modified, its complexity will increase

Complexity leads to:Software that is more difficult to maintainAn increase in the total cost of ownership


Watch for “Broken Windows”

One broken window leads to many broken windows...

Crack down on the little stuff to prevent the big stuff

Take immediate action to prevent further damage


Code Refactoring

The process of improving code without changing its overall result

Refactoring is not:Adding new featuresFixing bugs

Good times to refactor:As requirements begin to changeAfter a code review


Code Refactoring

Targets for refactoring:Code duplicationPoor architectureOutdated knowledge/logicPerformance issues

Leverage unit tests and test harnesses to prevent new bugs from being created


Communication


Justifying Maintenance

How do you justify allocating time for software maintenance to a project manager or client?

Explain that risk and cost increase when proper maintenance is not performed

Use the surgery analogyCatch it early = simple surgeryCatch it late = dangerous surgery and costly


“The problem with communication is the illusion that it has occurred.”

– George Bernard Shaw


Best Practices

In general:Use email so there is a paper trailAvoid hallway conversationsRespond to messages promptly

A quick “I'll get back to you later" response is better than nothing at all

Keep your audience in mind


Best Practices

With your development team:Assign a platform lead to coordinate communicationCreate a wiki to track wireframes, specs, and issuesLeverage a version control system

Include a detailed message with each commitConfigure it to send out change notification emails

Schedule regular status meetings


Best Practices

Actively seek feedback:At minimum, request a code review after each projectApproach people that you have worked closely with and ask them to be honestMaintain an open mind

Your critics are never 100% wrongDebate is healthy if both sides are open to change

Take responsibility:Admit your mistakesOffer options, not excuses


Time Management


Estimating Tasks

Crucial part of software developmentHelps prevent surprises down the road by forcing you to think about things up front

When asked for an estimate, always respond with “I’ll get back to you.”

Explicitly declare assumptions


Estimating Tasks

Unit of measurement is important in expressing accuracy6 months vs 26 weeks vs 130 days vs 1,040 hoursRough Precise

Leave your ego out of the equation:Don't try to impress others with a low number and then drop the ballGive good, honest estimatesAdd some padding to be safe


Work/Life Balance

It is very important to balance your professional and personal lives

The best developers find a way to sustain balance and avoid burnout


“If one oversteps the bounds of moderation, the greatest pleasures cease

to please.”

– Epictetus

© COPYRIGHT 2010 SAPIENT CORPORATION | CONFIDENTIAL

Ryan Taylor | [email protected] | www.boostworthy.com

Thank you.

mailto:[email protected]

mailto:[email protected]

http://www.boostworthy.com

http://www.boostworthy.com