If you happen to be a psychic: Quote of the Week

Just started reading Refactoring to Patterns.  Starts off with a good reminder that YAGNI.

When you make your code more flexible or sophisticated than it needs to be, you over-engineer it.  Some programmers do this because they believe they know their system’s future requirements.  They reason that it’s best to make a design more flexible or sophisticated today, so it can accommodate the needs of tomorrow.  That sounds reasonable – if you happen to be psychic.

Joshua Kerievsky, Refactoring to Patterns p.1

Look at the code you’ve written recently.  Were you pretending you’re a psychic?

But I really learned from writing: Quote of the Week

Note: Might be silly to call this a “quote of the week” given that it’s been years since I posted one but… oh well.

Heard this this morning on NPR from an interview with the composer Philip Glass:

What this amount of music has done for me is taught me how to write music. Oh, I had great teachers. Boulanger was one. Another was Ravi Shankar. And I went through the Juilliard process, and that was good, too. But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even dancers learn to dance. In a way, that's true. But what was the value of being so prolific? It's how I learned my trade.

Philip Glass from Philip Glass At 75: Listening With Heart, Not Intellect

What I heard in there is "But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even coders learn to code."

When people lack good information: Quote of the Week

Wow, this one hit my like a ton of bricks.

When people lack good information, they will invent some information themselves. When they don't know how well their project is doing, they will try to guess. When they don't know how other teams are performing, they will make assumptions. When they don't understand what their colleagues contribute to the organization, they will invent their own reasons. And when they don't know about their manager's personal life, they will gossip about it.

To prevent bad information from flowing through the organization you have to give people good information.

Jurgen Appelo
http://www.noop.nl/2009/03/great-managers-have-no-secrets.html

Jurgen’s blog has been a fixture in my RSS reader for quite some time and I’ve shared many of his posts in the past.  He has a knack for speaking coherently to issues that are very relevant to my situation.

As for the point he’s making here, I don’t think that, in most cases, information is “maliciously” withheld.  I do think some managers believe that certain information will just distract their employees and so they withhold it.  This tends to lead towards a vicious cycle where the employees are worried about the lack of information (and then the subsequent assumptions) which therefore makes the managers more concerned about distractions and therefore less willing to share information.

As developers we’re all about quick feedback.  We want quick compile times so that we can immediately know if we’ve broken something.  Unit tests give us additional feedback.  One of the reasons ReSharper is such a valuable tool is that it gives you information on potential problems quickly.  I want more information because it gives me a better sense of the overall context in which to make decisions about my code.

Quoting a quote from the post, “The concept is that the more employees know, and understand, the more they will partner and support the company's mission and goals.”  This is brilliant and yet at the same time very obvious!  The corollary is “only when employees care about financial figures, they will think of ways how to improve them.”  If managers don’t share information that gives employees feedback on their actions (how their actions impact the financial health of the company in the above example), then there will be no way that they will be able to effectively change things to improve without stumbling around in the dark.

No information leads to speculation and gossip which leads to incorrect information which is a poor substitute for correct information.  As Jurgen points out, the only way to clean out the system is to flush it with so much correct information that there is no room for speculation.

How many do you think?: Quote of the Week

I found this via one of my co-worker’s shared items.  It’s a variation on a theme that is oft repeated in the software development world.

I heard once that in Great Britain's MOD if you design software for a plane you go up in the test plane when the software is beta-tested. If all programmers were held with that level of accountability, how many do you think would still be in our field? How many would you want to collaborate with before you went up in the plane together?

Jay Fields
http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html

The problem is that not all software is equally critical (which the author does point out).  When asked what the right amount of process is, one of my college professors was fond of saying, “it depends”.  The right amount of process in situation A does not translate to the right amount of process across the board.  I would argue that the same is true for quality of developers working on a project.  This is not to say that it wouldn’t be great if every person writing software was awesome at what they did, but the reality is that there is more software to be written out there than there are great developers to write it.

So where does that leave us?  I think part of it is taking the good devs and making them great devs.  In Joel Spolsky’s Smart and Gets Things Done, he puts developers in three buckets, 1) Great developer, 2) Needs specific improvements and 3) Hopeless.  If you’re in management, culling out the “hopeless” is very important to team morale although I think that those cases are few and far between.  I think the great majority of developers are in the “specific improvements” bucket.  Getting your co-workers from group 2 to group 1 should be one of your highest priorities if you are any sort of management/leadership role.  Most “great developers” would probably put themselves in bucket 2, but the differentiator, for me, is that they are seeking out and working on those specific improvements themselves.  Inspiring those around you (not pointing the finger at those around you) is the way to improve the state of development no matter your situation.

Of course, if you’re surrounded by the “hopeless” it might be time for a change of scenery.  This advice might not be practical in the current economy, but remember if you can’t change your company, it might be time to change your company.

This was not decadence: Quote of the Week

Ahh, Joel.  You are a unending fountain of good quotes!

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1.

Joel Spolsky
http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

I think this quote brings out two interesting points that are a little bit at odds with each other.

1) The rest of the company lives to serve the programmer’s needs so that he can put out a good product.

AND

2) The programmer cannot exist in a vacuum and needs the rest of the company to support him or it doesn’t matter what kind of product he puts out.

So how to reconcile these two points?  Well, it comes when both sides recognize each other’s roles.  Each had different and important roles in the success of a software company.  I think the important point though is that in the scenario presented by Joel is that everyone is working together on the software, to improve the software, to give the programmers the tools and information that they need to create a delightful experience for the end user.

You won't grown neurons either: Quote of the week

Thanks to his (and Dave Thomas's) awesome and now "classic" book, The Pragmatic Programmer: From Journeyman to Master, I found Andy Hunt's blog.  (Dave also has a blog, and is on Twitter).  I'm actually hoping to read Andy's latest book, Pragmatic Thinking and Learning: Refactor Your Wetware in the next few months so I'll post a review once I've gotten there.

This week's quote actually comes from a blog posting from just a week or so ago and was very timely...

But here’s the funny part. The reason researchers had never witnessed neurogenesis previously was because of the environment of their test subjects. If you’re a lab animal stuck in a cage, you won’t grow new neurons.

If you’re a programmer stuck in a drab cubicle, you won’t grow new neurons either.

On the other hand, in a sensory-rich environment with things to learn, observe, and interact with, you will grow plenty of new neurons and new connections between them. A steampunk-etched notebook or a funky new pen is not just inspirational in some abstract way; the increased tactile sensory experience actually encourages growth of new neurons and stronger connections...

Your working environment is a context as well. It needs to be rich in sensory opportunities, or else it will literally cause brain damage.

(emphasis mine)

Andy Hunt
/\ndy (http://blog.toolshed.com/2008/12/science-failure-and-cubicle-brain-death.html)

I've been trying to make some changes in my life, mostly in terms of clutter.  I've actually been trying to apply the principles of lean software development to life in general.  I'll probably post more on that later, but for now, suffice it to say that I'm thinking of ways to be more effective and "live lean".  I was inspired by this zen habits post and have been contemplating Leo's minimalist workspace.  Do I want to have nothing on my desk but my computer?  It sounds appealing in some ways, but according to the study referenced in Andy's post, going to that extreme probably will kill brain cells!

I really like Scott Hanselman's home office.  He does a nice job of breaking down the things that you should have in any office where you spend a significant amount of time.  I actually got some of the Billy shelves from IKEA recently for home and they're pretty nice for how much they cost.

So, I have conflicting advice from two respected sources...  I could reduce the number of papers floating around, probably get rid of a lot of the stuff that I have stored and reduce the amount of unused "stuff" that I have laying around (both my home and work offices).  I have some desk toys at work, including a Ball of Whacks, which is a lot of fun to play with for me as well as for visitors to my office. 

I think the big this is to be more intentional with the things that are on my desk and the things I keep in and around my desk.  I need to do a better job of crafting the space around me, especially where I work.  Being more aware of your space and more purposeful with what you do with it can go a long way to improve productivity and possibly even stimulate brain growth!  I have some other stuff that I plan on bringing in, hopefully to minimize the drab gray colors of the (unpaintable :( ) office walls and create an environment "rich in sensory opportunities", cause I don't have any brain cells to spare.

Important is not a binary thing: Quote of the week

Joel Spolsky doesn't really need an introduction.  He's one of the rare people that you can refer to by their first name, people know who you're talking about.  He's so famous that there are people selling shirts referring to the man.

He hasn't been as chatty lately on his website as he was in the "golden years" of Joel on Software, so this is from a few years ago:

More importantly, I should have realized that "important" is not a binary thing, it's an analog thing. There are all kinds of different shades of important, and if you try to do everything, you'll never get anything done.
So if you want to get things done, you positively have to understand at any given point in time what is the most important thing to get done right now and if you're not doing it, you're not making progress at the fastest possible rate.
Joel Spolsky
Joel on Software (http://www.joelonsoftware.com/articles/SetYourPriorities.html)

I suggest you read that post, along with all the other old posts that he has in his archive.

As for the content, I find it interesting that this is one of the primary components of Agile development.  You don't do things in random order just cause they need to eventually get done, you work on what's important now.  Scrum gives you specific points to inject changes to the "what's important now" list but allows you the chance to focus for a sprint.

In any case, I think the challenge is being able to identify what is the "most important thing to get done right now".  I don't have all the answers and will probably post later with more thoughts on the subject, but since my "quote of the week" was quickly becoming a "quote of the month", I figured I should post something :)

Foosball: Quote of the week

This week's quote comes from Neil Davidson of Red Gate software.  They have some nice looking software that I've evaluated but haven't quite convinced my company to purchase licenses for us yet :(.  In any case, this isn't about Red Gate's software, but about Neil Davidson's opinion on foosball at software companies.

But the importance of interactions is wider than that. You need to encourage interactions between people in different teams, even different parts of the company. This needs to go beyond formal, sit-down meetings. It’s the random interactions that are valuable - conversations overheard in the kitchen and throw-away comments made over lunch at the pub. That’s why - once you reach a certain size - a foosball table, and a foosball league, are just as important as source control.

Neil Davidson
Business of Software Blog

One thing that I think my current workplace is failing at is facilitating a way to have those "random" interactions.  We recently moved offices (still need to post on that) and development (with QA) has their own section of the building with a separate break room.  This has resulted in little to no interaction between development and the rest of the company.

Now some of my co-workers would call this a win, but the more that I've thought about it, the less I agree with that sentiment.  Interacting with all aspects of the company is similar to the Agile philosophy that developers should actively engage with their users.  It gives you fresh perspective and helps you to see those other departments as people, not as a faceless mob that does not have your best interests in mind.

When I first started here, I decided to start up a weekly development group lunch in order to get to know people.  It's been a positive experience as I've gotten the opportunity to know many of my fellow developers that I haven't worked with and gotten to know those that I do work with in a non-work setting. 

One thing that is already in place is a quarterly department or company activity (alternates quarters, Q1 and Q3 are company, Q2 and Q4 are department).  That has been nice since it's company sponsored which means that we usually get everybody there.  They usually consist of lunch and then some activity.  They've included going to see a movie (Iron Man), snow tubing and laser tag which have all been fun.  It's been nice to interact with co-workers, especially from other departments, that I might not have otherwise interacted with.  Our recent annual user conference provided a similar experience as we worked together at conference.

I'd be nice if those sorts of activities (lunches, movies) were more regular though (and maybe more spontaneous?), at least on a department level (It'd be hard to spontaneously shut down customer support one afternoon).  A random "hey we're going to go grab some lunch and see a movie this Wednesday afternoon" or "we'll have pizza in the break room at noon today" would be pretty cool, probably more on a morale level then on a team building level, but in my opinion they are related.  I don't think you can have a great team without a certain level of morale...

(We actually did get the random pizza for the company once and it was really nice!  Hopefully we can see that again.)

I hope to continue to find new ways to facilitate random interactions among our developers and with the rest of the company and help our departments and company grow stronger as a team.  Maybe we can get a foosball table...

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.

Great Ideas: Quote of the Week

It's interesting that sometimes think we know what we want, but we really want something else.  And in the space between the two is usually where the really great ideas are born.  When somebody discovers what we really want instead of continuing to give us what is we think we want.  Of course, this is a similar idea to the one discussed in the Innovator's Dilemma, another book on my "must read" list.

... many of the great ideas are not precipitated by the customer. While the customer knows what he wants, he doesn't always know what's possible. And that first dawned on me in my earliest days in business. When I was new at IBM, working in sales and taking a management training program in Sleepy Hollow, New York, I came back to my room grumbling about the lack of speed and reliability of the tape drives, and wondered why the engineers couldn't do something about it. My roommate stared at me with a look of total exasperation. "Boy, you guys in sales are all the same," he said. "You remind me of the farmer in 1850. If you asked him what he wanted, he would say he wanted a horse that was half as big and ate half as many oats and was twice as strong. And there would be no discussion of a tractor."

David Kearns, former CEO of Xerox

The Art of Programming: Quote of the Week

A good one from the Pragmatic Programmer guys...

The art of programming lies in that nether region between the hopeful wishes of an elegant architecture and the hard grindstone of technical details.

Andy Hunt and Dave Thomas

Ashton's Law: Quote of the Week

Alan Ashton is the man behind WordPerfect.

Ashton’s Law: Whenever someone tries to do something for you, they usually end up doing it to you.

Alan Ashton, 1974

Bruce Webster actually published the quote in his Remembering Ashton's Law post which gives a better understanding of what it really means...

Quote of the Week

I post a "Mike's Quote of the Week" on the outside wall of my cube each... well most weeks.  Here's the one I just posted:

When you actually sit down to write some code, you learn things that you didn’t get from thinking about them in modeling terms. There is a feedback process there that you can only really get at from executing some things and seeing what works.

-Martin Fowler