Obie Fernandez

Can I Find an Agile, Design-Savvy iPhone Developer?

DueProps has been needing an iPhone app for for a few months now. However, I don't have the time (or frankly, the inclination) to prepare a detailed specification for how it should work. I also lack tens of thousands of dollars to give to an agency to take care of it for me. The last few times I've searched for the right candidate it's been pure frustration.

If I could wave a magic wand to produce my ideal iphone developer, I'd conjure someone who:

• ...could start to come up with a workable design for the app after spending a few hours talking to me and familiarizing themselves with the way that DueProps works
• Understands iterative development. I don't need the app to be perfect or include all possible functionality all at once. The core of what I need is super simple. Login. Choose a prop. Give it to a colleague on your DueProps network or to a new user via their email address. View latest activity. The backend for all that is already there.
• Speaks fluent English
• Works independent (of an agency) for a reasonable hourly rate, say $30-50/hour

Does such a person exist? I can't be the only person wondering...

EDIT: If the rates I mentioned are too low and a proper rate for (as one commenter put it) a "multi-faceted pro" freelance is more like $100/hour then is it possible to get a simple, finished product in 2-3 weeks at most? Because otherwise it's seriously blowing my budget.

I guess I could approach this as wanting a fixed-bid contract for my budget amount, which is $10-15k, but fixed bids have always scared the hell out of me.

Hiring me as a consultant

While my web startup DueProps consumes most of my time, I don't make any money from it yet and probably won't for awhile. So I pick up short term consulting gigs from time to time to help replenish my savings.

What I offer is honest and experienced advice, but not deliverables. If you've followed me for awhile, then you know what my areas of expertise are:

• Growing a consulting operation from scratch
• Leadership of web development teams
• Adoption of Agile and Lean Startup techniques
• Ruby on Rails-related technology (I can pair-program with you or your team)

Hiring me as a consultant is really easy. You may purchase my time at an hourly rate or a daily rate. What you get:

1. distilled knowledge and advice
2. a no bullshit approach
3. advice on demand

I will not try to sell you anything else if you hire me and I’m not interested in ongoing retainers. I might want to give you a free demo of DueProps, but that's just cause I'm so in love with the positive impact it can have on workforces.

To book my time, we just need to have a preliminary conversation about what you want to achieve by hiring me. I don't have problems with signing an NDA, if you require it. Once we officially book our billable time together and execute a simple consulting agreement, I’ll get whatever I need from you to prepare and be available for advice on demand via phone and email.

Getting down to specifics on pricing, if you want to book me hourly, I’m $300 an hour, billed in 15 minute increments.

If you want to book me in person on a daily basis, it's $10,000 a day plus travel and accommodation expenses. Booking a full day of my time is more expensive and involved because of the disruptive nature of travel and the need for more preparation. The precise schedule of a daily engagement doesn’t matter as long as we spend about 8 hours talking or working on your project.

To book a day with me looks like this:

1. We sign a mutual NDA because while I'm on site I may share confidential stuff with you
2. You share all documents and resources that we’ll be discussing at least a week prior to the trip
3. We agree in writing on expectations for our time together, so that I can be 100% prepared

Since I live in Atlanta and you probably don't, booking me for a day will usually involve me traveling to your location. You will take care of booking the travel and accomodations and cover the cost. I only fly Delta Airlines (first class) and I only stay at Hilton Hotels.

That’s it. The terms are transparent and non-negotiable. My email is obiefernandez@gmail.com I can help you win.

--

Hat tip to one of my heroes, Mr. Tincup, for inspring me to describe this offer in this way. You should hire him for marketing advice.

where are un-ordered tools?

While digging up some stuff on my old blog I found this post: The new dynamics of strategy: Sense-making in a complex and complicated world that I published back in December of 2004. Almost 7 years later and I'm not so sure that we've made progress with real-world tools leveraging this research.

The authors coin the term un-order in much the same sense as undead, to refer to "emergent order". Not an absence of order, but instead the patterns that emerge from situations which undergo continual change, subject to chaotic influences. This is of particular interest to the agile community and particularly XPers, whose motto isembrace change, which explains why it seems to be getting a lot of attention from agile bloggers. I see a window of opportunity opening up for a slew of open-source projects that build on this information. While reading Wisdom of Crowds, I got the strong impression that a far-flung organization (such as the the consulting company that I work for), will benefit by moving agressively on these knowledge management advances. For instance, devise a polling tool with differing modes that match the various identities that we live on a day-to-day basis, namely: consultant, coach, manager, member of our client team, member of the parent company. Within each of these modes, features that allow referendums and continual feedback for all levels: personal, team and organization.

Maybe Asana is a step in the right direction? I've been using it with my new startup as our project management tool for everything that doesn't fit into Pivotal Tracker. Liking it so far.

The Next Big Leap

In my view, FITness, Cucumber and other acceptance test frameworks represented a big leap in software development effectiveness because they allow coders to get intimately involved with (and in some cases replace) Product Management/QA roles. Extreme Programming has developers working directly with product owners and capturing their requirements as "acceptance criteria" on story cards. Eventually, the desire to automate acceptance testing and best practices for how to express acceptance criteria led to GIVEN-WHEN-THEN support baked into actual testing frameworks such as Cucumber.

That's okay, but it's not nearly enough. Let's talk about how the next big leap in effectiveness is going to happen. Assume the following story is true:

• Given a specification for a feature that has not been demonstrably linked to business value,
• When a developer works to deliver an implementation of that feature,
• Then the worth of the implementation work is indeterminate until some future time when its business value is validated

Most feature requests that I've ever worked with in the early stages of a project, are ideations of the product visionary/designers/entrepreneur, based on intuition rather than customer feedback. And that's perfectly normal and acceptable to me. The more innovative a creation, the more work you usually have to do before you put it out in front of customers and get meaningful feedback. But the impact of those features on key business metrics are assumed, if it gets any explicit thought at all.

Aside: As for the implementation of those feature requests, I'm going to assume that being faithful to the specification is implicit, as it should be when we're talking about professional programmers. (Not working with professional programmers? GIGO)

Given those assumptions, I think what myself and others have realized as a problem with so-called "high-ceremony" adherence to methodologies such as BDD (Behavior-Driven Development) is that by obsessing over correctness of the implementation as faithful to the spec, it becomes easy to lose sight of the true value of our work: to deliver business value, as measured by key business metrics. We may obsess over crafting pristine, bulletproof, maintainable code, and yet its worth is indeterminate at best. And why, as developers, would we be satisfied with that!

"Measure as much as you can - no feedback == no direction"  Hugo Rodger-Brown

How can we establish that our work is not a waste of time? One technique that I hope to work on in near future is the specification validation of business value right in my acceptance criteria as part of its test cases. Said differently, I am looking for an easy way to specify non-functional requirements as part of acceptance criteria in such a way that it is automatically tested. It would be an extension or evolution of the current BDD toolset, not a replacement. You can even use de rigeur GWT syntax:

Given the implementation of email notifications,
When 100 customer events have been processed,
Then the mean time between events metrics should improve by 30%

or better

Then the net revenue per event should improve by 30%

or best

Then the net revenue per event should increase by $100

I care more about business value than faithful adherence to a particular functional requirement. My specifications should reflect that mindset. What makes this whole approach non-trivial is the challenge of establishing credible causal relationships in my acceptance criteria, given the multi-variate nature of dozens of interleaved features in a particular application and the way that key business metrics overlay many features at once.

Despite the challenges, I think the concept I'm describing is the next big leap. The first challenge is to get people talking about it and definition of goals. The second is to design a methodology and technical framework for accomplishing those goals.

What do we call the whole thing? Business-Driven Development? (no) What do we call the specs? Can you write specs against metrics in a tool such as KissMetrics? It's hard (or at least has been for me) to figure out what metrics I need until after I've written the features that yield measurement data used to calculate those metrics. How do I fix or at least improve that workflow? How do I describe the discipline needed to think of the metrics prior to specifying a feature?

Right now all I'm trying to do via this blog post and my public comments is to start a dialogue. I'm not trying to make any blanket statements about the correctness of BDD/TDD or testing in general, just pointing out that there's lots of room outside of that particular box for innovation.

As for my comments at RailsConf and Goruco, it seems to me that at a startup that has not achieved market fit, it's wrong to spend much time ensuring that a given piece of software matches its functional specification. (Specs that often won't exist, because the same person specifying the functionality is the person writing the code, in which case I'm saying don't bother writing the specs. Just "cowboy" it and do a complete rewrite later if it proves necessary.) Once you have your MVP, write specs for how particular code changes will impact key business metrics. Regressions will probably fail to improve key business metrics.

The question is not "should I test (or spec)", but rather it is "what should I test?" As an industry, to the extent that TDD/BDD has caught on at all, I don't think we're testing the right things, with our emphasis on correctness of implementation. When we figure out how to rigorously test for business value it's going to be the next big leap. That's a big green field waiting for all of us to play in and I want to be one of the first.

The Dark Side Beckons?

Lord Ries by Cody San

For years I've advocated a high-ceremony, test-first development methodology where use of BDD (or TDD) is sacrosanct and uncovered production code is a sin. Then I got to know Eric Ries and studied his Lean Startup stuff and got started with my own lean startup venture and over time...

Something's happening. I'm not the Agilist I should be. I want more. But I know I shouldn't.

I no longer believe in high-ceremony development practices for early-stage startups. Actually, I'm pretty sure that they're poisonous for most web startups, hence my lightning talk at Railsconf 2011. Until you are able to prove that you have a viable market, that customers will give you money for your product, you shouldn't be sinking a lot of time and money into implementation. Assuming you are a competent Rails developer, you should be able to hack out features and take on quite a bit of technical debt to build throwaway proof-of-concept versions of your product. I'm pretty much advocating construction of large "spike solutions" except that unlike the traditional XP definition, the problem you're trying to solve is the problem of finding your market fit. It has nothing to do with the technology.

Also, we are commonly told that spikes (aka prototype systems) are not meant for production and should be thrown away. I think that advice is very dependent on the skills of the people writing the prototype system. If they are experienced developers, they're going to inherently know a lot of the application patterns that should be used and the amount of technical debt introduced will be low enough to feel comfortable with the app in production.

Some caveats:

• I'm specifically talking about typical web-based applications built with Rails where nobody is going to die if you occasionally get a 500 error on an edge case. Use continuous deployment so that you're comfortable that you can turn around code improvements and bug fixes almost immediately.
• Use TDD to "discover" the design of parts of the system that are unfamiliar to you. This primarily applies to unit testing
• By all means have some integration-level specs that test the "happy path" through your system so that you don't inadvertently break your entire app. AKA "smoke tests"

Early on in the startup process, it's much more important to be testing against business metrics than anything having to do with code. One of the most thought-provoking pieces of advice I've heard lately came from Hiten Shah of KISSmetrics who told the latest LSM NYC crowd to consider the effects of a feature of key business metrics to be the acceptance criteria for that feature.

In other words, before you implement a feature, you should have an assumption that tells you what the effect is going to be: higher click-through, engagement, satisfaction ratings, etc. This results in an acceptance test that is time-shifted; you won't know the results until you deploy. I believe this is fertile ground for technical innovation. While there are plenty of frameworks that simplify AB testing and real-time monitoring, I don't believe there exists anything along the lines of Cucumber that involves developers in cultivating a mindset of provable business value. David Chelimsky and I joked around that perhaps such a tool should be called Squash.

One of the natural questions that arises from this line of thinking is: When am I no longer an early-stage startup? The implication being that at some point, you know enough about your market fit and product requirements that you can transition into what I've been calling high-ceremony development practices.

I don't have the answer to that question. I suspect that the size of the development team has a lot to do with how you'll want to answer that question for your own effort, because multiple workstreams on a single codebase has a tendency to skyrocket technical debt. All of the above is premised on your ability to keep technical debt in control -- I have no doubt that irresponsible dependence on technical debt will kill your company just as effectively as relying too much on financial debt -- I've seen it happen.

The bottom line is that once again I find myself rejecting dogmatic adherence to a particular mindset. And contrary to my initial metaphor, that doesn't seem evil at all. Maybe I got it backwards and the high-ceremony Agilistas are the dark side, and the lean startup hackers are the Rebel Alliance... what do you think?

Stocking Stuffer: Mental Notes

I've now bought a few of these Mental Notes decks for the Hashrocket offices. Each card (52 in all) has an insight drawn from psychology that can help you with brainstorming and problem solving. They arrive in an attractive faux leather box and the whole package seems like a great little Christmas gift. I'm not making any money from this referral -- I just think they're great.

Mental Notes (about $50 incl. shipping to US destinations)

Get the first 7 cards as a PDF download

Competitive Research Series: Part I

Early this year, I commissioned a competitive research project with the goal of producing real insight into how other web design and development shops out there do business. The results were interesting, to say the least, but due to time constraints I haven't been able to do much with them. I'll be sharing highlights of the data with you over the coming months, starting with this introductory blog post.

First, an explanation of how the data was gathered. First we helped our researcher, a potential entrepreneur with a good idea, to flesh out his web startup concept (involving social media and e-commerce). We crafted the scope of the project to correspond to the type of complex web application work that Hashrocket has designed and built on budgets ranging from 100 to 500 thousand dollars. The project details were crafted well, probably beyond what was necessary in order to do the study.

Over the course of a month, our entrepreneur painstakingly contacted a total of 103 web design and development companies, primarily via email. 54 of those companies followed up to some degree or another, ultimately leading to in-depth conversations with 42 of them. That leads to one of the first eye-opening revelations of this study: Almost half of the companies we contacted didn't follow up properly or at all. In fact, about 6% of our initial contact emails bounced! Has that much of the industry gone out of business this year? Or is email that unreliable a contact method?

It is difficult to discern whether the firms that ignored initial contact did so because they were careless or simply too busy. Perhaps the work didn't interest them? One well-known firm had an auto-reply message to the effect that they were too busy to respond to anything other than urgent requests, adding that their lead time for starting new projects was at least 3 weeks or more. Ballsy.

I will not be identifying any of the companies researched, although I will say that many well-known shops were on the list, including one behemoth that ended up being excluded from much of the results by merit of being such an outlier (ahem). The list of companies to contact was first drafted by naming the shops we know off the top of our heads, then enhanced with shops found via Google searches and a variety of online resources including:

    ⁃    FirmList.com

    ⁃    RailsDevelopment.com

    ⁃    Sortfolio.com

Our entrepreneur purposely tried to contact providers with a variety of technology specializations (not just Rails shops) and did not express a preference for a particular technology, instead asking the shop to give their preference. As you can see in the graph below, we were able to include a healthy number of PHP and .NET shops.

Somewhat surprisingly, but perhaps due to our small sample size, none of the shops expressed a preference for Python. We also were not able to talk to that many Java shops. Perhaps Java really is losing steam as a mainstream web technology?

The size of the companies studied varied quite a bit. In a future entry in the series I plan to analyze a bit more carefully the smaller end of the spectrum, but for now I'll simply give you a graph showing the distribution by headcount.

We also got data on the years in business of the companies contacted and what kinds of people they employ.

 

By itself, the years in business distribution seems somewhat even and perhaps doesn't say much, but I hope to break down some of the other data in relation to maturity of an organization and hopefully yield some interesting results.

On the other hand, the employee type breakdown did surprise me. The vast majority of the firms we spoke with claimed to employ only full-time employees (FTE) rather than a mix of FTEs and contractors. Even less used only contractors, with a significant fraction of the mix being shops with a main market presence and offshore development resources. 

 

When we asked companies about the average years of experience of their developers, most said "it varies," which we took to mean that junior developers would be involved. Fifteen percent gave us a number between 1 and 3 years, which doesn't inspire much confidence! 

 

Over half of the companies we spoke with were willing to share annual revenue figures, with the rest declining to answer for confidentiality reasons or simply not knowing.

 

We're guessing that many of the numbers we were cited were make-believe, because the variety of revenue figures was very surprising, especially when analyzed in conjunction with head count to derive per person revenue numbers. Could the spread in profit margins really be that wide?

 

 

The next entry in the series will delve into hourly rate data, which I'm sure you don't want to miss.

 

My RubyConf India 2010 Talk Highlights

Hashrocket sponsored the inaugural RubyConf India event primarily to support the nascent, yet growing community of Rubyists here, but also due to my personal love of Indian people and culture. I've been eager to get back to Bangalore for the last couple of years and this was the perfect excuse. I deliberated about what talk to deliver to this audience. At all costs I wanted it to be entertaining and provocative. In my opinion, too many Indian service companies are "doing it wrong" -- they stick to the stereotypical modus operandi of offshore providers, with waterfall processes and fixed bid. I wanted to impress on the audience that there is a better, more fun way to run your business. After opening comments by the organizers and Roy Singham, Chairman of ThoughtWorks, I delivered the second general audience talk.

I was charged up with the right kind of anxious energy and this being material that I know inside and out, it came straight from the heart. The talk was not entirely new, previous versions of it had similar material. However, I did go through and restructure the outline significantly as well as adding new material based on the last 12 months of operations at Hashrocket. Luckily I also added some elements that I knew would appeal to my audience -- slides based on the blockbuster Indian movie "3 Idiots". Little that I know how important the concept of "All Izz Well" would prove to be to myself!

On a scale of 1 to 10, I would rate myself a 9 on delivery. I was funny and engaging, making eye contact with the audience members and spending much time in storytelling mode. Unfortunately, I would have to deduct points for making the mistake of dropping the "F-bomb" too many times and as a result getting interrupted and vocally dressed-down by Tina Vinod halfway through! Somehow, although nervousness infected my voice and I started forgetting to breathe, I did pat my heart and tell myself audibly "all izz well, all izz well" and charged ahead with my talk -- the audience got a good laugh at that. Other challenges included the organizer mistakenly telling me I was out of time when I actually had at least 15 minutes left! Luckily my Keynote display presenter mode with its timer saved me. I did pick up the pace a bit, but finished in 48 minutes, just 3 minutes over my alloted time.

Reading List

In the section of the talk about Process and Practices, I mentioned that it is necessary to go "by the book" when starting out. Too many people criticize practices that they haven't properly implemented. You must learn to crawl (so-to-speak) before you can evolve your own practices. 

The list of books I recommended constitute a large part of the orthodoxy of progressive software development nowadays. I asked the audience, how many of you have read at least half of these books. Sadly, only a dozen or so hands (out of 400) shot up. I truly believe that you cannot be effective nowadays without studying these books and applying them to your day to day.

Agile Software Development, Principles, Patterns, and Practices

Agile Retrospectives: Making Good Teams Great

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

Design Patterns: Elements of Reusable Object-Oriented Software

Domain-Driven Design: Tackling Complexity in the Heart of Software

Extreme Programming Explained: Embrace Change (2nd Edition)

Refactoring: Improving the Design of Existing Code

Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

Software Craftsmanship: The New Imperative

Test Driven Development: By Example

The Principles of Product Development Flow: Second Generation Lean Product Development

User Stories Applied: For Agile Software Development

Working Effectively with Legacy Code

 After you've mastered the fundamentals, then you can begin to evolve your process and practices to actually achieve the best results for your context. I must have said 20 times during my talk that "context is king."

 

One of my favorite and most controversial pieces of advice, at least based on the feedback and comments that it generated:

"I don't defend breathing... I don't defend Agile. It just is."

I believe unequivocally that the time to be evangelizing and advocating proven Agile techniques is over. It's been at least 10 years since Extreme Programming hit the scene. We know that TDD yields excellent results. We know that pair programming yields excellent results. We won. To continue being in defensive mode against stupidly obstinate management is a waste of time. It may take a long time from now, but eventually people that don't work in smart Agile ways will fail and go away. As for you, concentrate on being excellent, perfecting your craft and building a loyal and devoted group of clients that will provide you with strong references and testimonials.

If you want to put into practice my advice, refuse to work for clients for whom success is not 100% important. This will necessarily exclude most large enterprise clients, where politics and status quo are as important as results. Those types of clients will drag you down and make you compromise your values. Startups and entrepreneurs usually are 100% focused on successful results. These stakeholders will not be worried about your technology choices or whether you want to pair program and do test-first. They will let you do your job, and the way that you sell them on using you is with successful track record, demonstrated by copious amounts of testimonials from previous clients. I stressed the importance of photos and videos to capture the spirit of your success in a vivid and emotional way. We have the technology -- use it!

 

My advice to fire clients if they need to be fired was perhaps shocking. It shouldn't be. I've only had to fire a client a few times in the history of Hashrocket. That's considering a list of now almost 60 happy clients of all shapes and sizes. The key to not having to fire clients, is to not get the wrong clients to begin with. This is known as being able to "choose your clients." It's not as hard at it seems. Sure, when you're starting out it is somewhat difficult to put this advice into effect and you will make mistakes. That's when it's important to have the confidence to cut ties and look for greener pastures.

"Never allow your clients to corrupt your values or integrity."

The worst thing that can possibly happen, more than having money difficulties, is to corrupt yourself by compromising on your values and integrity due to pressure from a bad client. I'm not saying to be inflexible! I'm saying that there are core values that will allow you to reach for excellence and achieve it. You won't know what those values are when you're starting out, but you can be informed by studying the successful results of others and internalizing that knowledge. Then when you're on a roll and doing great work for your clients, you will realize what those core values are. From that moment on, no matter how big the pressure is, you should not compromise. The more confident you are about your way of working, the easier it will be for you to sell your services and acquire quality clients. The last thing you ever want to do is to appear desperate -- at that point great clients will go away running and bad clients, those that will take the worst advantage of you will become very friendly! Never allow your clients to compromise you. Stick to your values and focus on success.

When I'm evaluating software developers to hire, I don't give much credence to resumes, cover letters, referrals or work history. The only things I care about are work ethic and cultural fit. And there's only one way to determine whether a candidate satisfies my criteria for success -- actually see them in action over the course of a week or more. Since we always pair program, it is trivial to do short contract gigs with qualified candidates and bring them in putting them on multiple real projects. Seeing them working on real code in real situations is very instructional. Again, context is king. Over the course of time, we've created a very desirable work environment at Hashrocket, which means that there is a strong demand for people to come work with us. That means I can diverge easily from traditional hiring models.

Conclusion

Indian business culture, at least the stereotypes that are propagated to the west, doesn't strike me as particularly fun. But if you're doing great work for your clients and sticking to your core values, then you're going to have a lot of success and be able to enjoy it by building a very fun work environment. My final series of slides was a photo set of various fun activities that Hashrocket folks engage in on a regular basis, from participating in user groups, to music and sporting events, games, having parties, drinking and dancing and doing crazy stunts like all jumping into a swimming pool at the same time.

I truly believe that if you're not having fun at work, you're doing it wrong. A happy, healthy environment is one that leads to the best results. However, you can't impose fun on a group by fiat, just like you can't create culture. It has to emerge from hiring happy, progressive folks that want to do the best work possible while sticking to strong core values. This is the final message of my talk and I hope that the audience found it inspiring and worth passing on...

 

Great CS Program for Girls Needs Funding

Started in 1996, Artemis is a nationally recognized outreach program to encourage girls from local public schools to pursue careers in Computer Science, and more broadly in science and engineering.

From their website description:

The Artemis Project is a free, five-week summer day camp for rising 9th grade girls in the Providence area who are interested in learning about science and technology. Traditionally, it has been run by four undergraduate women from Brown University in connection with Brown's Computer Science Department. This year, Artemis is pleased to announce that we will additionally have a coordinator from Boston University.

By teaching students computer skills, programming, and computer science concepts through engaging activities, the Artemis Project encourages young women to join the field of computer science. According to my friends in DevChix, early experience in computer programming is essential to stemming attrition rates among women in CS programs at the university level.

So here's a great opportunity to help sustain a program that has been getting girls excited about CS for 15 years. Artemis needs to raise $25,000 to keep the program going this year. My company, Hashrocket, will be making a sizable donation. If you or your company also is able to donate, you can do one of the following things...

1. Send a check made out to "Department of Computer Science, Brown University, Artemis Program" to:

Amy Tarbox
Department of Computer Science, Brown University
Box 1910, 115 Waterman St.
Providence, RI 02912

2. Donate online by going to https://gifts.development.brown.edu/Brown/ChooseGifts.aspx and under the "Other Current-Use Priorities" section, fill in "Artemis Program"

For more information on potential sponsorship arrangements, contact Amy Tarbox: abt@cs.brown.edu

What does Quality mean to you?

 

The tag map above is an artifact of a discussion about quality that we had internally at Hashrocket last Friday. The question was: "How do we measure Quality on our projects?"

Many of us felt that money (budget) or rather, adherence to the client's budget was the best way to judge quality. I took that to indicate awareness and constant refinement of the quality/speed ratio.

Interestingly, lifestyle (pace) ranked highly, which I think is a reflection of our core values. A comfortable, stress-free environment and sustainable pace is an essential factor in production of quality software. However, I don't know if you can use lifestyle indicators as a quality measurement.

Customer satisfaction ranked highly as well, but perhaps not as high as the others because customers are not always clued in to the real level of quality in their application? Hopefully some of my rocketeers will chime in with their opinions about that.

The answer with the most votes by far was craftmanship, which itself needs further discussion to define well and understand. As a group, we brainstormed ways to measure craftsmanship and ended up with the following ideas, not weighted:

 

How do you define quality and craftsmanship? Tell me in the comments.

By the way...

I absolutely have to tell you about a great consultant that we retained at Hashrocket to spend a couple days with us discussing quality and helping our management team to figure out growth plans for 2010. His name is Steven M. Smith and I met him at the AYE Conference in Phoenix last month. Besides being a great management consultant, Steve specializes in experiential workshops. You should definitely consider hiring Steve to help you with your software development company or department.