Your brain is too small - Quote of the Week

This week's quote comes from the classic, Code Complete: A Practical Handbook of Software Construction.  If you're not familiar with McConnell's body of work, I suggest you get on that... as per the quote:

Once you admit that your brain is too small to understand most programs and you realize that effective programming is a search for ways to offset that fact, you begin a career-long search for ways to compensate. In the development of a superior programmer, curiosity about technical subjects must be a priority.

Steve McConnell
Code Complete 2nd Ed. p822

Well, he doesn't say you have to be curious about his books specifically, almost every book he's written could be considered a software development classic, so I'd say that it's definitely a good place to start.

I firmly believe that being a software developer is like walking the wrong way on a moving walkway.  If you aren't consistently working to improve and expand your skills and knowledge, then you're falling behind.  Unfortunately that means that one day you could wake up and realize that you've just been laid off and your skill set is 10 years behind the current state of the art.  Or that the development practices that you picked up in school might not be the best ones in the world.

I've been happy that at my current company we have a department reading program (not as developed as I'd like, but it's a start) where we read a book together as a department and then discuss it in our weekly department meeting.  I think that it's been a real eye opener to some as we've read Code Complete, The Pragmatic Programmer and are currently reading Head First Design Patterns.

But aside from whatever your company sponsors, make sure that you're constantly exploring new programming topics.  This can be via books, blogs, trying new languages, attending user groups or code camps and picking the brains of those around you that have more experience.  If you're not curious about what's going on in your field, you're never going to be a superior programmer.

What do you do to scratch your curiosity itch?

What a shame. What a waste.: Quote of the Week

This week's quote actually comes from marketing guru Seth Godin.  I love his blog because his posts are usually short, focused and insightful.  This morning I was reading through my mountain of unread posts in Google Reader and found this post from Seth for this week's quote:

Growth is frightening for a lot of people. It brings change and the opportunity for public failure. So if the astrological signs aren't right or the water is too cold or we've got a twinge in our elbow, we find an excuse. We decide to do it later, or not at all.

What a shame. What a waste.

Seth Godin

As I mentioned before, I post this quote outside my office (we've moved to a new space where I now have an office... more on that later) each week so I didn't include the rest of the post (didn't want them getting too nervous that I'm going to bolt) which says:

Inc. magazine reports that a huge percentage of companies in this year's Inc. 500 were founded within months of 9/11. Talk about uncertain times.

But uncertain times, frozen liquidity, political change and poor astrological forecasts (not to mention chicken entrails) all lead to less competition, more available talent and a do-or-die attitude that causes real change to happen.

If I wasn't already running my own business, today is the day I'd start one.

One of my goals is to start my own business.  I've actually done it once (the now defunct DressModestly.com, Inc.) with my friend Rich Arthur and it was a good experience, but I'd really like to work on something I'm passionate about instead of something that just seems like a good opportunity.

In any case, I've been thinking about it off and on for some time but with everything going on in the world started to think "dang, this probably isn't the best time to be doing things like starting a business" but of course Seth proves me wrong.  My recent birthday has caused me to reflect on what I'm getting done with the time I have.  A line from one of my all time favorite movies, The Music Man, came to mind, "You pile up enough tomorrows, and you'll find you are left with nothing but a lot of empty yesterdays."  I don't think today I'll be doing anything :(, but I have been discussing things with another good friend, Jon Turner (also known as theparticleman) and we have a few ideas and we're going to start working on something in the coming weeks.

So, don't be scared of growth, personal or professional.  Don't look for excuses not to do things because you'll always find one.  Don't waste away your career and your life "prudently" wasting opportunities.

Inventory of Software Development: Quote of the Week

This comes from the Poppendieck's book Implementing Lean Software Development under the section on "Eliminate Waste".

The inventory of software development is partially done work. Partially done software has all of the evils of manufacturing inventory: It gets lost, grows obsolete, hides quality problems, and ties up money. Moreover, much of the risk of software development lies in partially done work.

Tom and Mary Poppendieck

I really like the whole idea of minimizing the tasks that are "in process".  If you think about it, if I have 3 tasks that will take me 3 days each and work on them all "simultaneously" there are a few problems.  One, at the end of 3 days you still have nothing done, and if you are truly working on them in parallel you won't see any results until the 7th day.

Even more dangerous is work that is perceived as "done" but isn't really done.  One of the great things about Scrum is that you need to think about what "done" really means.  Many projects out there don't get anything "done" and, as such, end up with the hare's problem and must "declare bankruptcy" frequently to clear out the "excess inventory".

Now this doesn't mean that you "get it right the first time".  Often you will need to redo something that was previously "done", but leaving things undone because they might change is just a recipe for disaster.

Clever Vs. Wise: Quote of the Week

Not specifically a software quote but from a pretty smart guy.

A clever person solves a problem.
A wise person avoids it.

Albert Einstein

No Obvious Deficiencies: Quote of the Week

This is an oldie that I found way back when I was still in school...

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare

It is often our tendency as developers to make things more complicated than they need to be.  To counter that tendency, one of the Agile mantras is YAGNI (Ya Ain't Gonna Need It).  This is often hard to do because instead of designing and building huge frameworks up front, it means that as things are needed they have to be implemented or possibly current functionality has to be refactored to fit new features.  Very difficult for management, and often very difficult for developers!  "Just do it right the first time" is often the counter to this, but one of the difficulties is that "the right way" is often not clear until you've journeyed down the path a little bit.  And if you guessed wrong at the start and did not leave flexibility to choose a different path, it is harder to change then if you had waited.

Lean Software Development gurus, Tom and Mary Poppendieck, refer to this as "deferring commitment" until the "last responsible moment".  This doesn't mean that you hem and haw about things forever since usually that results in the "last responsible moment" passing you by which is as worrisome as making a decision too early.  (Mary gave an excellent Google Tech Talk on this principle called "Competing on the Basis of Speed" which I highly recommend.)

Like Goldilocks, we need to be in constant search of the approach, complexity and timing that are "just right".

Even simple requests become arduous to implement: Quote of the Week

This one is from Tim Barcz over at Devilicio.us.

A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test. It's a common hurdle for those new to testing to say, "I don't have time to write tests." Let's face it, we're all busy, that excuse is tired. As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool. While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing. Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development. Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement. Slowly you see your velocity come to a crawl.

Tim Barcz

We're dealing with this very problem where I work now.  We reached the point where "even simple requests become arduous to implement".  But we are well aware of the traps that our predecessors fell into, one being that they gave up on unit testing under schedule pressure.  All that technical debt built up to the point that we are now declaring technical bankruptcy.

What does that mean?  Well, basically we're starting from scratch.  The original code wasn't built to be unit tested even though the original programmers wanted to do testing and even started to try.  But classes were highly coupled which made testing arduous.  And, unfortunately, instead of recognizing this as a smell, they pushed onward, declaring unit testing too complicated and time consuming.

So now it's our job to level out the graph and make the transition to a tortoise, pumping out a steady stream of reliable, well factored and unit tested code.

Egoless Programming: Quote of the Week

This is a hard one but an important one.  I found this quote on Jeff Atwood's Coding Horror blog on an old post that was referenced from a current one.  (It'll be nice to one day to be able to refer to myself as well as others in my own posts!)

Egoless programming occurs when a technical peer group uses frequent and often peer reviews to find defects in software under development. The objective is for everyone to find defects, including the author, not to prove the work product has no defects. People exchange work products to review, with the expectation that as authors, they will produce errors, and as reviewers, they will find errors. Everyone ends up learning from their own mistakes and other people's mistakes. That's why it's called egoless programming. My ego is not tied to my "perfect" or "imperfect" work product. My ego is only tied to my attempts to do the best job I know how, and to learn from my mistakes, not the initial result of my work.

Johanna Rothman

It's hard to sit there and watch your work get pulled apart and examined by somebody else and to take it and be constructive with it.  I know my first reaction is to throw up the defenses and start giving excuses or pushing that it's fine how it is.  BUT I do it because I know that it improves my code and improves my programming skills.