Squeejee Blog - Latest Comments

Re: We're Hiring! - Squeejee

lisa — Wed, 08 Jul 2009 23:21:35 -0000

I can't tell you how much I'd love to help you. I have a background working in usability at Apple, Sun, Adobe, and others. It's a passion and obsession I just don't seem to be able to kick. I love your stuff, your site, and your attitude. Anything I can do to help, let me know.

MFA, CalArts (Animation)
Everything from design and testing to you name it re usability
Active community organizer re healthcare reform
Managed multiple projects simultaneously & successfully for Farallon/Netopia

You guys do a terrific job. How can I help?

www.ljroseOnline.com

Re: Free advice for AT&T - Squeejee

ljr — Wed, 08 Jul 2009 23:12:18 -0000

I just found you guys. THIS IS GREAT!!! YOU GO with this-completely agree. I worked in usability at Apple and Sun and I am completely with you Chris. I have some lists I'd like to give you guys of stuff like this.

Adding on to the above great recommendations:

GET YOUR PAPER and e-BILLING together. What a mess. It's 2009. There is no reason for the sad state of the information design of your billing, AT&T. How about starting by hiring a REAL graphic designer to help with this vs. just giving this to somebody who happens to think they can move columns around to make the bill more usable. Horrible. And get a clue about fonts.

Hey Chris, Can I come join you in your campaign? I'm totally with you on stuff like this.

Re: Free advice for AT&T - Squeejee

Jay with Scrub Tops — Mon, 22 Jun 2009 02:25:27 -0000

AT&T is either deaf or just playing dumb...They're not listening to the complaints against them, and there are a lot of them. They are not making any changes to make their services better. They're going down one of these days...it's called karma.

Re: Free advice for AT&T - Squeejee

ms.wxyz — Sun, 21 Jun 2009 10:08:25 -0000

hey all at & t just simply sux have never in my life delt with such an agonizing term in my life than the 3 yrs with them for my mobile phone....i left ..went to virgin .....3 yrs of the same phone line and they wanted a 750 deposit .

they think since they have had 5 different names we just do not know thay are still ma bell

Re: Build an App, Start a Movement. Our RailsConf 2009 talk - Squeejee

Luigi Montanez — Sun, 10 May 2009 14:03:05 -0000

Are the slides for the MongoDB lightning talk posted anywhere? I'd really like to see that.

Also, the video I took for the presentation above should be posted soon!

Re: TweetCongress wins at SXSW! - Squeejee

pengwynn — Wed, 25 Mar 2009 08:21:17 -0000

Thanks, Giovanni! It was nice to meet the team behind I Am Second. It's a beautiful site with a beautiful message.

Re: TweetCongress wins at SXSW! - Squeejee

giovanni gallucci — Fri, 20 Mar 2009 13:25:17 -0000

Well done guys! Please let the record show that we were second though!

Re: Why we bill by the hour

Rick — Mon, 23 Feb 2009 14:38:37 -0000

Since when did clients become the enemy? Clients are the life's blood of my business and I am grateful for them. Perhaps you should find a career where you don't resent people so much.

Re: Free advice for AT&T - Squeejee

ryan — Sat, 14 Feb 2009 12:08:42 -0000

amen to 1-5. Just so you know though # 6 is a bit more tricky. the fact is that the phone networks suck bad and really verifying that you really are who your caller ID says you are. it is quite trivial these days to spoof an outbound caller ID, as anyone that has worked with VoIP can tell you. so that is a problem with the phone network in general, not just AT&T

Re: Things to Do if You Want to Work for Squeejee - Squeejee

TBone Steak — Sat, 24 Jan 2009 17:41:19 -0000

Shockingly, as a designer I did manage to get a job with (looking back on it) a painfully neglected site and portfolio. However, when the interviewer asked me about what I had been paying attention to, they noticed that I had been faithfully dedicated to my then current position. What they saw was potential.

Most of my personal sites are, to some degree or another, neglected because I work more on my client sites than my own. What good am I if I just make my site shiny, but not the client's site? Sadly, I've missed out on some positions because I took the time to craft a thoughtful resume, but they received far more than they could handle. I'm still busy and don't have much time to work on my own sites, but it's getting better.

Re: A fresh coat of wax - Squeejee

Curtis Jennings — Fri, 21 Nov 2008 11:14:47 -0000

you all rock.

Re: A fresh coat of wax - Squeejee

Cal Slayton — Fri, 14 Nov 2008 19:41:57 -0000

Thanks for the shout out.

Re: A fresh coat of wax - Squeejee

mully — Thu, 13 Nov 2008 12:47:01 -0000

Love the new look!

The Webby platform looks very promising so far too!

Re: Why we bill by the hour

Will — Fri, 29 Aug 2008 17:34:00 -0000

Nice article Chris.

@cak -
We all have experience estimating how long it will take to complete a project. Remember, this is an _estimate_. The accuracy of the estimate depends on a number of things including the level of detail at requirements gathering and how much things change before the final delivery.

Just because you are Agile doesn't mean you do not estimate. From a long-term planning perspective you can still provide the customer with a time estimate. However, it is generally recommended to broaden the estimate the larger a project becomes. If it is a one year project, estimate that it will be completed Q3 2009. As you get closer to the end of the project, you can refine the target, like Sept 2009 or as you get even closer, a real date like Sept 26, 2009.

With a high-level time estimate, the customer can still budget for the project. You can give the customer a rate and a time estimate. Let them do the math. They will see that the project will cost them between $150,000 and $200,000.

One of the purposes of Agile is to give the customer what he wants, not what he wanted. A waterfall approach without communication with the customer during development will lead to delivering a product the customer will not use. With Agile, because you are in constant contact with the customer, providing regular updates on the product, you will be able to adapt to the customers changing needs.

The beauty of an Agile project is that the customer is able to provide feedback continuously. Many times this means delivering a better product in less time. The customer gets exactly what he wants and saves money at the same time.

All that said, if you are a company without a lot of credibility (like a start-up), many times you don't get to call all of the shots. If the customer demands a fixed bid, perhaps you take it because you need the revenue. However, you can still apply Agile principles within a fixed bid project. Change management just becomes harder with a fixed bid.

Re: Why we bill by the hour

Thibaut Barrère — Fri, 29 Aug 2008 11:26:00 -0000

I do fixed bid if and only if the "project uncertainty" is very low. Known customers, with a relationship of quality, when the project has little technical risk and when the project or the iteration size is under 20 days of work.

Otherwise I bill by the day, where the day as a fixed amount of hours, for the reasons you gave.

Re: Why we bill by the hour

cak — Fri, 29 Aug 2008 10:57:00 -0000

You are completely wrong about this. Basically you are saying that you can't estimate how long a project will take, so you are not taking responsibility about this. This is a very important part of the process, judging how long a project will take and the amount of resources you need to throw at it, and you are saying that you CAN NOT do this. How any of your customers take you on is testimony to the ignorance or stupidity of your customers.

So you say you can still work with a company who has a budget for your project, but in reality you would use up there money, have half the project done, and therefore nothing to show for the money they have spent. They would either have to write of the money they have spend, or get money to finish the project. Rather than have a guarantee of deliverables. Once again, this is ridiculous.

I can't believe you are proud of the fact, and seem to brag about the fact that you can't estimate a projects time. If you can't estimate how long a project is going to take, how can you estimate how many resources to throw at it, or even if it can be done?

Re: Why we bill by the hour

Chris Tingom — Thu, 28 Aug 2008 22:22:00 -0000

Really great post. We've been tracking time and billing hourly for about 2 years now. I've really enjoyed it and it has made us and our customers more efficient.

What software do you use to track your time?

Re: Why we bill by the hour

kevins — Thu, 28 Aug 2008 21:45:00 -0000

The whole point of software is to leverage the ability get paid multiple times for doing something once -- you can sell lots of copies, charge recurring fees for hosting/support/etc or, ideally, both.

If you're writing code and getting paid for it exactly once, you're either a chump, or that's all you're worth.

Re: Why we bill by the hour

toolhater — Thu, 28 Aug 2008 16:32:00 -0000

albertg is gay. if you are worth a shit and better than just run of the mill, companies will ask for an estimate AND give you and hourly rate.

the other way around is simply the way cheap companies deal with shitty programmers.

Re: Why we bill by the hour

Kevin — Thu, 28 Aug 2008 15:12:00 -0000

Plenty of other professions (e.g. lawyers) bill by the hour, and somehow manage to survive... the concept isn't revolutionary. It's a matter of honestly setting expectations and not over-promising.

As to the argument that clients will just multiply rate by hours to derive a de-facto fixed bid - it's your job to clarify the nature of the beast: it's at least partially a subjective endeavor, and since changes have a cost to you, they have a cost to them.

Truthfully, there's a bit of a Catch-22 baked in: it's much easier to convince clients that you won't go wildly over the estimate if you have a body of existing work (and satisfied customers) to point to, but of course you need to land some contracts first. But that's common to starting out in general, and not endemic to the issue of how to price your work.

Re: Why we bill by the hour

Rick Bradley — Thu, 28 Aug 2008 15:12:00 -0000

I agree in part, and I disagree in part (with the original article and most of the comments).

A fixed bid job that spans anything more than a single agile iteration runs into the problems of rigidity, working against agility, lack of mobility wrt "critical" change requirements. It's not, in my experience, workable to fix a bid for anything past a single iteration.

On the other hand, customers do want to contain risk (basically ALWAYS), and uncontained price growth is one of the most significant risks.

One further issue that's not been mentioned is efficiency. If developers are working at an hourly rate the incentive is present to take as much time as possible in order to maximize pay. This runs counter to what one would want as a professional, as a craftsman: an incentive to learn one's craft so well that one becomes increasingly more efficient at it.

I would counter that the contention that a fixed bid ends up with clients getting taken to the cleaners is actually worse with the hourly rate: hourly developers, unless they continually practice discipline, tend to bill clients for time spent doing mundane things that would be automated away under a fixed-price structure.

I recommend a middle ground that addresses most of the risks:

* Jobs are estimated on a per-iteration basis, documented with a Statement of Work. An iteration is something like 1 or 2 weeks of work on a well-defined list of stories.
* The work for the iteration is estimated and given a fixed cost.
* Work that is "emergency" work, changes to scope, unforeseen but critical, etc., is billed at an hourly rate high enough to justify doing it, high enough to discourage thoughtlessness, but low enough that the client can see paying it.

In my personal experience, some deviations apply:

* If the work is on a system (and/or with other developers) that is such a mess that even single-iteration estimation is not possible, then the work is to be done hourly, at a high rate. But it becomes our responsibility to show the client why this is so. The majority of our clients don't have this problem, but the few who do are pretty aware of the mess they're already in.

* Some clients want a long-range estimate (say 6+ months). In that case we do more story work with them, do very rough estimates, explain to them why Agile works, and give them an estimate on the high side and provide documentation to the effect that this is in no way accurate, binding, or even in the realm of reality. If they insist on pinning down some effort/cost structure for a pie in the sky project we either multiply the estimate by a non-trivial factor, or we refer the client to someone else.

The short-term fixed bid has a number of advantages:
* it actually limits some of the client-side risk by fixing price
* it limits some developer-side risk by fixing the scope being tackled, and forces developer-client communication as developers are shouldering the risk of implementation
* it limits longer-term risk by refusing to include risks that can't be studied or addressed in the current iteration
* it forces developers to produce deliverable software on a per-iteration basis, as the customer can (and should be able to) go somewhere else for the next phase of the project
* it forces developers to become more efficient at their jobs, as inefficient developers end up with a low effective hourly rate
* it allows developers to potentially raise their effective hourly rates if they deliver valuable work to the client in a short time frame

If a client is willing to pay (say) $8K for a two-week iteration of working software that covers the 20 stories that end up in the iteration, and there's noone else in the market who can beat that price, I would contend that the iteration is worth $8K. If the developers end up spending $10K worth of time to deliver it they're not doing well, but have an incentive to improve. If they end up spending $6K worth of time implementing then they're doing better than the market average. Are they ripping off the customer? I would say no: they're shouldering the risk, charging what the market will bear, and being paid for becoming efficient at what they do. If they do shoddy work or if the market won't bear the price then their price must come down, otherwise I see this as a fair market transaction.

All that said, I've seen this in personal practice. My company has been the "back-end" (or "guest stars" in the client's parlance) for a couple of HashRocket "3-2-1 Launch" releases. Basically this means that for a fixed bid we come in and produce a working application *in 3 days*. We have been comfortable with doing that, everyone has found the results (both software and money) great, and it's single-iteration fixed bid work that requires us to be highly efficient at what we do.

Best,
Rick

Re: Why we bill by the hour

Sid Savara — Thu, 28 Aug 2008 10:46:00 -0000

I think this depends on the job, and the level of trust the client has in your abilities. If you're talking about multiple man month projects in particular, I agree it's flat out irresponsible to claim you'll do it for X dollars in Y days with Z vague requirements.

Re: Why we bill by the hour

Venkat — Thu, 28 Aug 2008 06:52:00 -0000

While what AlbertG says makes sense, most customers today are willing to see some reason. We work exclusively on hourly billing and this is the same argument we put forward to our client. While I worked with PeopleSoft and Oracle, I have had a similar experience while bidding for fixed bids. It's just not right to do fixed bids anymore. I tell my customers, happily, to choose another vendor who will do fixed bid if they wish. I also tell them that once they are done with them, I will be happy to do this for them from scratch.

Re: Why we bill by the hour

Donald — Thu, 28 Aug 2008 06:01:00 -0000

I agree with Albert G. The client will simply multiply your rate by the number of hours you estimate.

Re: Why we bill by the hour

albertG — Thu, 28 Aug 2008 05:49:00 -0000

Uhuh, you've got it all worked out haven't you? Unfortunately, in reality clients still expect an estimate of some kind. If you don't give them a fixed price they want an estimate of hours and if you don't give them either they walk. No sane customer will give you an open ended commitment to paying your hourly rate until the project is complete.

The client simply multiplies your hourly rate by the expected time to determine the expected price, which becomes your defacto fixed bid and you're right back where you started. Go over your time estimate and you have to deal with all the same issues you would have to otherwise, go under and you're losing money with respect to a fixed price.

The heart of the matter is this type of work is for fools. Developers aren't happy because they can't afford to do a good job, and are at the mercy of the irrational dictates of the client. The client might occassionally be happy, but only because they're ignorant of the pile of shit that's been delivered to them.

In other words: consulting work is bullshit, build products and sell them instead. But that might require learning something of economics and re-evaluating your attitude to open source.