Archive for May, 2012

code smells

Here’s a slide deck on code smells in ruby I recently put together to show our development team.

Once everyone has an idea of why understanding and reducing code smells is important, then the benefit gets distributed when others use knowledge in pull request reviews.

Categories: tech

open source

made a open source contribution to the Chronic gem last night.  as always, feels good to help out the community.  we use other people’s open source work, we give back.

Categories: tech Tags:

a great software development project

I’ve had a long history of working on software projects. This history started off in C & then moved to Pascal, C++, C#, and now to Ruby/Rails. I’ve worked in consulting, IT, a handful of big name software shops (Microsoft, Amazon, RealNetworks), and smaller name software shops (Symyx, G5). I’m currently very pleased with the project i’m on, and wanted to share some of my observations of what i think makes this great software project, and a few other observations I’ve learned along the way.   I consider the below points a team & project recipe for keeping good people happy and delivering value.   My current company is G5.  My current project is G5 Reputation Manager

Here goes..

People. Keep teams small, focused, autonomous.

Keep the team small Small teams collaborate and focus better. Hire people that can communicate. Keep people that can be entrusted with autonomy. As much as possible, separate corporate minutiae from your project. Find another building to locate to if necessary. In hiring,  I’ve seen much better team dynamics and productivity by avoiding the “ninjas, rock stars, hackers, big egos”. You can tell a lot about people thru their twitter feeds. Try to hire a developer on contract for 6 months before bringing in full time. Probe candidates on how interested they are in continual self-improvement. For teams, I think the ideal team size is 2 developers (4 max) and one business owner. That’s it. No QA team to throw code over the fence to, no PM team. The strongest of these team members is the lead. The lead keeps on top of the team’s cadence and best understands the business problem. The lead inspires great work from the team.

Tools. Stay mainstream, lightweight…and delighted!

I am not religious about Ruby & Rails and I prefer to not work with people that consider their tool a godsend and refuse to consider others.  That said, i’m super happy w/ the expressiveness and beauty of the ruby language.  The value of this cannot be understated.  It never ceases to amaze me how deep the Rails community is…there’s a gem for nearly anything you might want to do.  If not, build it and contribute!  On our Ruby Rails project, I’m using a mainstream toolset in our stack that works great (& is invaluable to my skillset):  Pivotal Tracker,  Rails 3.2.3, Ruby 1.9.3,  Rubymine (vi), git, mysql, redis).  You want to maintain rhythm on delivering value to your customers, not spending days worrying why your CI server isnt working w/ your SCM.    Stay on current version w/ ruby and rails!  it gets harder to upgrade in Rails the further you fall behind.  A great suite of tests is invaluable for upgrades.   Use frameworks (like Twitter bootstrap) to speed things along.    Use a collaboration tool like Campfire or FlowDock for team communication (but turn off your growl notifications!)   What i like about FlowDock is the message inbox & the git/airbrake-rss/PivotalTracker integration.  We use AirBrake for exception notifications.  This tool has been great to show us where test coverage is needed and where our customers might be experiencing repeated problems.   

Agile.  Stay lean, short iterations, measure and pivot.

Start the project with a MVP.  Make your best stab at scratching a 10X itch.  Build in ways to measure the features your customers are using.  Pivot, improve, or kill features or direction as early as possible.  What good is it to spend 6 months of your team’s time to build a product that isn’t scratching the right market itch?   Be ruthless about eliminating waste:  don’t do standups if you’re not getting value from them;  don’t insist on pair programming if your team doesn’t favor it.   Stick to the essence of agile:  short iterations, adaption, quick feedback.  The rest will work out.    

Work environment.  Kill the distractions.  Let in natural light.  

Don’t skimp on a quality work environment.  Distractions are the biggest enemy of productivity.  Give developers a quiet, distraction free workspace with lots of natural light.  Natural light improves mood, health, and productivity.   Provide a walking desk and standup pairing stations.  Also, most developers love to work at home occasionally.  If working at home is producing quality commits to git, i’m all for it.   If a developer goes dark, nip that problem early. 

Quality.  It’s not optional.

When we started this project, even under big pressure to deliver yesterday, we started it off not compromising quality.  All code is reviewed, either thru  pair programming or git pull request reviews.  We measure code coverage (simplecov) every few weeks to check for missing holes.  We use flog to measure code complexity and refactor the trouble spots.  Our project code is idiomatic Ruby & well-tested…mostly thru isolated unit tests, and thru some higher level acceptance tests.  I prefer TDD, but dont insist on it.   With TDD, you know your tests are good and you know you’ve written just enough code to pass the tests.   But, depending on the context, sometimes I like writing tests after the code.   I think it’s important to allow some freedom in how developers like to work.   No compromises on making sure your tests are fast!   We do this by isolate business code from framework code as much as possible, isolated unit test the business code and integration test the stack.  Tests are written to the same quality standard as production code.  Make sure everyone on your team is experienced in recognizing code smells, using design patterns,  understands the importance of tests.   Dont be afraid to call out quality violations.  Set the quality bar high early on.   

Leadership.  Ya gotta have it. 

The self organizing team is a myth.   I’ve seen countless examples of great individual skill assembled as a team flounder without a clear leader.  Find, cultivate, and reward developers that show a propensity to lead, understand the business, and stay on top of technology.  Rails programmers can be found at any time.  But a strong technical leader is worth their weight in gold.  

Support the community. Find a way to contribute to open source.

Imagine life with ruby, rails, and the thousands of great gems out there.   We are using open source in our project and we owe something back.  It feels good to contribute. 

Organizational support.   A must have. 

It’s exciting when your CEO comes by your office and gives you real customer feedback on your project.  You’ve scratched a major itch!    It’s also exciting when your CTO pays you a personal visit at your home to let you know about a major customer event evangelizing your project.   It’s been a boon for us that all our project’s stakeholders have aligned priorities.   

Deployment.  Use the cloud. 

We’re using EY cloud.   Easy setup, easy deploys from git, and the best thing is easy spin up of staging clones to do topic branch testing.   When a topic branch is done, it’s reviewed, merged, and deployed.   It’s a joy that i can finish a topic branch, spin off a clone of production and test it there before deploying to production. 

Cadence.  Keep it reasonable & w/ smart use of time-boxing.

Give developers work-time/place flexibility and minimize distractions.  If > 40 hours are necessary, offer developers the option to be paid by the hour or gain a meaningful equity stake.   Dont expect more than a 8 hour day.  Even better is to measure on quality of output, not hours worked, and dont be a time-card puncher.   Treat your team with dignity and respect for their families and wellbeing.  Use meaningful deadlines & showcase-driven time-boxing (e.g., a trade conference where your product is being demonstrated) to maintain workable pressure and then celebrate when you’ve crossed the finish line.   But dont over use the time box or it will suck your team’s soul dry and you’ll find your developers quickly updating their linkedIn profiles.

Rest.  Enjoy.  And celebrate.

Humans are hardwired to pulse.  Pay attention to your physiological needs.  Take frequent breaks.  I like Pomodoro as a tool to encourage focus and force me to take frequent breaks.  Drink lots of water,  eat healthy, and exercise every day.  Sleep as much as your body needs.  Relax.  Your brain and body will thank you.   When you get great news from inside or outside your company, celebrate!    Do fun outdoor things with your team mates that dont involve coding!  Take frequent vacations.  Enjoy being alive and productive.

I hope others find this useful. p.s. I am indebted to my friend, Rails mentor, & co-worker Chris Kraybill, CTO at G5.

Categories: tech
%d bloggers like this: