My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
You have a sales meeting that generates a Statement of Work. The statement of work includes a lot of fluff and a few line items. In your first development meeting with the client, you pitch the possibilities of what the system can be, thinking it's obvious the dream you're describing will require more contract hours. However, given all the fluff in the original SOW, the customer assumes it can be done under your current agreement. Subsequent meetings revise the project features downward until the customer sees the deliverable: in their eyes, it's a bottle rocket. But you've built more than you ever thought you agreed to - it's a bona fide spaceship.

Focus on your customer's feelings, be clear about deliverables, and if you don't intend to deliver the fluff, don't talk about it as if you do. Don't design contracts and project meetings around making yourself feel warm-and-fuzzy. Stroking your ego like this makes you feel like a hero who under-promised and over-delivered. Unfortunately, the customer got the opposite impression.

How is it that two groups of people experienced the same phenomenon, yet come away interpreting it world's apart?

Miscommunication and failure to manage expectations.

If you fail to communicate and verify what was understood was what you intended to say, you're liable to set expectations much higher than you can possibly deliver. That leads to pissed-off customers, or worse: past customers.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

There was once upon a time I held some affinity for Expert'sExchange. I tried hard and succeeded at becoming an expert. I thought it might look good on a resume and in fact I got a few offers of job and freelance work from it. More...

This is the first in a series of my answers to Jurgen Appelo's list of 100 Interview Questions for Software Developers. Jurgen is a software development manager and CIO at ISM eCompany, according to his About page.

The list is not intended to be a "one-size-fits-all, every developer must know the correct answer to all questions" list. Instead, Jurgen notes:
The key is to ask challenging questions that enable you to distinguish the smart software developers from the moronic mandrills.
This list covers most of the knowledge areas as defined by the Software Engineering Body of Knowledge. Of course, if you're just looking for brilliant programmers, you may want to limit the topics to [the] Construction, Algorithms, Data Structures and Testing [sections of the list]. And if you're looking for architects, you can just consider the questions under the headings Requirements, Functional Design and Technical Design.

But whatever you do, keep this in mind:
For most of the questions in this list there are no right and wrong answers!
Keeping that in mind, I thought it would be fun for me to provide my off-the-top-of-my-head answers, as if I had not prepared for the interview at all. The format will first list the question, my initial response (to start the discussion), followed by a place I might have looked for further information had I seen the questions and prepared before answering them.

Though I hope otherwise, I may fall flat on my face. Be nice, and enjoy. More...

I'm not talking about Just-In-Time compilation. I'm talking about JIT manufacturing.

When you order furniture, it likely gets assembled only after the order was received. Toyota is famous for doing it with cars. You can do it yourself with JIT published books. On top of that, Land's End offers custom tailored, JIT manufactured clothing.

It's easy to say, "yes, we can publish software in the same manner." Every time we offer a download, it's done just in time. This post was copied and downloaded (published) at the moment you requested it.

That's not what I'm talking about either. More...

When someone starts complaining about customers who are making silly requests, I normally say something like, "I know! If it weren't for those damn customers, we'd have a perfect program!"

There'd be no one using it, but hey - the application would be sweeeeet.

This week I'm going to diverge from Chad's book on how to save your job. That's mostly because I don't have the book with me, but this has been on my mind the last couple of days anyway: the fear of success.

I've noticed it in myself and others from time to time - inexplicably sabotaging opportunities to succeed. I try not to listen to that voice now if I can help it.

More recently, I've started to notice it in companies and customers as well - groups as opposed to individuals. I've started wondering if reluctance to "go live" until the product was a symbol of perfection fits in with this phenomenon. More...

Last week I posted about why software developers should care about process, and how they can improve themselves by doing so. In the comments, I promised to give a review of what I'm doing that seems to be working for me. So here they are - the bits and pieces that work for me. Also included are new things we've decided to try, along with some notes about what I'd like to attempt in the future. More...

In this week's advice from MJWTI, "The Way That You Do It," Chad Fowler talks about process and methodology in software development. One quote I liked a lot was:
It's much easier to find someone who can make software work than it is to find someone who can make the making of software work.
Therefore, it would behoove us to learn a bit about the process of software development. More...

I was in a conversation recently about our mission and vision statements, and how it is important to have them as a model of what your company is trying to do, and what it would like to be doing in the future.

It got me to thinking about why, as a programmer, it is important to understand the basics of business.

Without understanding the company mission or vision, how can you support the business goals and aspirations? Without knowing them, how can you understand them?

We're in the process of redefining ours. What are yours? Do you have a personal mission and vision for your career? Can you boil it down into a couple of concise sentences?

That's one I'm going to have to think about. But I'd love to hear your ideas...

Relating to customers is something I like to be reminded of from time to time. After all, we're not in this business to be code-monkeys. Our actions serve some purpose, and that purpose is not generally to chunk out code. In other words, code has no intrinsic value. Its value is realized in the business purpose it serves.

(One caveat - I suppose the code written in Office Space and similar schemes had intrisic value, since it's purpose was its value.)

The customer from hell has been brought up in a few places recently. Most prominently at Peter Bell's blog (and within the comments), and also by that kinky student, Ben Nadel in the comments to being passionate about your job.

In one of Peter's posts, he asks if developers create bad clients. Certainly we can (and do) create bad clients, but at what rate is it our fault? If I had to guess at a number, it would be "a lot."

People will generally respond as you'd like if you just take the time to communicate your wishes with them. As Peter noted, our indecision, mishandled errors, and badly positioned boundaries will tend to create those clients from hell. And what do all of these have in common? It appears to me that they all revolve around poor communication.

I've been thinking about that one today - about the clients I couldn't stand and contrasting those relationships with the customers from whom I couldn't wait for a new project. In every case I could think of, I had poor communication with the bad clients, and excellent communication with the good ones. Some of the bad communication was the customer's fault - they simply didn't have the time to devote to a project or didn't care to do so. Most of it was my fault.

That's not enough to prove anything on it's own, since the type and amount of communication could have been a result of self selection. I might have chosen to communicate with the customer's I enjoyed working with, and refused to talk with the dreaded ones. But you have to admit, it's at least an interesting coincidence.

Asking the right question
This post relays some wisdom from Scott Davis's keynote speech at NFJS in Austin a little over a month ago. The talk was titled, "No, I Won't Tell You Which Web Framework to Use... (or The Truth, With Jokes)."

He talked about a lot of different things, but the point of the talk didn't really have anything to do with web frameworks, or computers in general. It was about choice, markets, crowds, and questions. It can be applied easily to the software we build, but it can also be applied equally to other things in general. Well, at least that's what I came away with. More...

As I've mentioned before, I used to try my hardest to avoid contact with the customer, and as software developers, I think we don't spend enough time concerned about the business aspects of what we do.

In My Job Went to India, Chad Fowler says he thinks so too.

To combat code monkey syndrome, Chad suggests we have lunch with business people and read trade magazines for our business domains as often as we can. More...

I can only very slightly see the purpose behind angering your users so you can keep the results fresh - but there are better ways to to it - such as polling the server in the background rather than invalidating the session and forcing the users have to re-enter their search terms every few minutes. It's even worse when you invalidate the back button and I can't see my old search results, or if you provide a button that says "return to results" that takes me to enter my search terms for the 10th time.

Sorry about the rant, but it's quite annoying. I can understand doing it unwittingly by accident, but when you're viewing data that doesn't change frequently from someone as "professional" as company X (whom provided the app that prompted this post), it's completely unacceptable, and borders on absurd (on the absurd side of the line). The amount of data that will change frequently enough to justify keeping it that fresh is only very small. When I click on a link to find more information about it and come back 5 minutes later, I shouldn't have to search again, much less re-enter my search terms.

Have you found any valid uses for this? And again, I want to reiterate - I can understand if you want to keep the view updated - but there are MUCH better ways to do it. Even many of the travel sites use it to their detriment (IMO), and I don't understand it.

Update: I've taken out the specific references in this for three reasons:
1) It occurred to me that it is quite unfair to criticize the implementation of an application when I haven't seen it and don't know for sure what I insinuated about it is true.
2) It is also unfair to criticize a specific product after only using it for a couple of minutes.
3) I didn't want to spread rumors about the cost of something when I wasn't completely sure.

Basically, I went a little off the deep end and this is my attempt to come up for air =). My apologies to anyone offended that I took it down (or put it up in the first place). But really, the essence of the post remains in tact.

Last night in my Management Information Systems class we discussed a case about using Second Life as a marketing tool. We were lucky enough to have the professor who wrote the case study present it to us (or walk us through discussing it). For the first half of the session, we discussed as a class the relative benefits and reasons to do it against the drawbacks and reasons not to. In a 30 person class, only 3 people initially saw the investment as a good one. My own misgiving was echoed by at least one of my classmates: with a narrowly limited budget, is spending it on an unproven idea the best course of action - especially when the density of person/land area seems so small in SL? After discussing, we were even luckier to have Matt Nixon, the Director of E-Commerce for STA Travels, North American Division. It was his idea to get his company a presence on Second Life, and now he was here to back up his decision. More...

I think that as developers, we too often ignore business objectives and the driving forces behind the projects on which we work. Because I'd like to know more about how to think and analyze in those terms, I decided to take a course about Management Information Systems this semester in grad school. One of the papers we read particularly stuck with me, so I thought I'd share the part that did: When we undertake a risky project (aren't they all?), we should consider what competitive advantage it will give it, and if that advantage is sustainable.

To measure sustainability, Blake Ives (from University of Houston) and Gabriel Piccoli (from Cornell) identify four barriers to erosion of the advantage (this is within a framework they present in the paper, which is worth reading). The barriers are driven by "response-lag drivers," which the authors define as "characteristics of the firm, its competitors, the technology, and the value system in which the firm is embedded that contribute to raise and strengthen barriers to erosion." In any case, on to the four things we should consider: More...

A couple of weeks ago, John Roth posted a link to Martin Fowler's article on Customer Affinity on the XP yahoo groups list.

I just like being reminded that we shouldn't be thinking "those awful customers want something else done now! Can you believe it?" I think we have those thoughts far too often. I know I used to.

I used to be the type who would actively try to avoid conversations with the customer - get some manager to do it. I've since stopped that approach, but every once in a while I find myself thinking "well that's a stupid idea." In the past, I'd either just do it to get it over with, or tell someone else to tell the customer it was a stupid idea (in more diplomatic terms, of course).

Now, I find it much more helpful and rewarding to discuss (without the use of a proxy) the objectives they are trying to reach with the "stupid idea." I've found a lot of times, the ideas aren't that stupid. Other times, I can suggest a different approach that would solve the problem in a more meaningful way. Still others, I've talked myself out of good paying work that didn't need to be done because of an unfounded fear of a potential problem.

I don't think you can develop good software without understanding the goals of the customer for whom you are writing it. And how can you understand the goals without having that "customer affinity?"

It's a pity so many waste so much time developing software that is essentially useless. I always smile when I hear the "go get this done and come back in 6 months with the finished product" stories. That used to be me, and I mostly always came back with the wrong product.

I like my newer approach much better, and I like to be reminded from time to time about it. That's what this article did for me, and it's definitely worth a read.


Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner