Cage Match

14 10 2011

As I’m currently on the bench between engagements, my company sent me out to interview for a gig with a small local company that creates third-from-the-bottom-tier websites for startups.

Let me explain what I mean.

A bottom-tier website, in the definition I’ve chosen to use here, is one that serves up nothing but static data: that is, it’ll have a front page with your company’s name, logo, contact information, and a blurb or two about the business you’re in, recommendations from previous clients, and so on, but it’s essentially just a point of presence on the Web that gets you into search-engine results and not much more.

A next-to-bottom-tier website is one that has some functionality behind it, but that has been created without any programming expertise using one of a hosting company’s standard creation wizards.  Maybe there’s a user database and a shopping cart and an RSS feed, but they’re all standard building blocks hooked together in a standard way by the site owner without any build-time interaction from developers.

A third-from-the-bottom-tier website, like the ones this company creates, has the same active building blocks, but there’s also a comparatively small amount of real custom business logic involved that has to be coded by real developers.

The operative issue for this company is that since the startups (two- and three-person companies) it works for don’t tend to have big budgets, it has to complete these simple websites quickly–sometimes on the order of just hours, more often in a month or less, occasionally as long as three months–so that it can afford to hire developers who are capable of doing the work.

To that end, the company depends heavily on Spring Roo and several custom plugins that let it generate most of the code for a new website in just a few minutes so that they can spend the rest of the time on cosmetics and business logic.

So I was interviewing with the CTO, and I spent some time arguing with him about whether his small budgets and reduced cycle times would be better served by an Agile process or by the compressed-SDLC/waterfall process he was using.

I’d like to explore some of these questions a little further here, but I’m hampered by two things.  First, there’s my obvious prejudice in favor of Agile.  Second, while the CTO has obviously read a fair amount about Agile, he has never had any direct experience with it, leading to certain misconceptions that couldn’t be addressed in the space of a job interview.  Perhaps interested readers can compensate for these failings, where they appear, in the comments.

Issue: No interaction with the customer between requirements specification and demo of finished product

CTO’s position My position
The customers, by and large, are not technical people and don’t care about technical issues. We’re the technical people. If we run into requirements that are not completely specified, we use our heads to make the best guess and build it in, and the customers are generally fine with that once they see it. Technical people should decide technical issues; but non-technical issues are not really their forte. If a non-technical requirement isn’t completely specified, it’s probably because the specifier didn’t think about it especially hard; perhaps if he had, he would have uncovered completely new requirements without which the project will be significantly poorer.
If we show the site to the customers before it’s done, they’ll want all kinds of other stuff too. They’ll creep the requirements, we won’t get finished by our deadline, and we won’t get paid. Creeping requirements are a good thing, not a bad thing. It means the finished product will come closer to meeting the customers’ needs. Also: more requirements, more money. Don’t deal in time: always work on what the customer thinks is most important right now, and let them stop paying you when the money is worth more to them than the next feature down the priority list.
Our customers are tiny two- and three-person companies. They don’t have time to be constantly babysitting us: they’ve got more important things to do. If we send them a question requesting clarification of a requirement, it may take them two or three days to respond, and their response may just immediately prompt another question. Our schedule doesn’t allow us that kind of time to be waiting around. It’s true that an Agile development process requires high-bandwidth communication with the customer. I feel like this one’s a good point. My best response would be: which is worse, having a feature be blocked for awhile, during which time you work on another feature, or wasting time and funds developing the wrong thing?

Issue: The first time a product sees production is after it’s completely finished.

CTO’s position My position
Almost all our websites use exactly the same components, and we deploy them all the same way on the same hosting service. We know the route to production very well, and have it mostly automated; there’s no reason for us to deploy more often. It’s a good point. There are two reasons for pushing to production early: first, to get a handle on the process; and second, so that your customers can see the product early. You’ve already gotten the first taken care of, and you’re intentionally eliminating the second.

Issue: Project is not deployable until development is complete

CTO’s position My position
We work under very tight schedules; we don’t have the time to spend repeatedly making the code deployable. If you had continuous integration running automated tests, you could easily fix it so that your code was deployable whenever CI was green.
Even if we could get quick at it, there’s no need to deploy early. If you had constantly-deployable code, then customers who ran out of money early could have at least something for the money they had already spent, rather than nothing.  A customer who has run out of money is an unhappy customer, but a customer who has run out of money and who gets nothing for the investment he’s already made is an unhappier customer.
That would require customers to be constantly looking at the product.  Our customers don’t have time for that: their days are full of appointments. Then they’re accustomed to appointments.  One of those appointments could be a weekly demo of the product, closely guided and sharply focused just on what’s been developed that week.  You’d be done in half an hour.  You could leave that version of the code running over the next week on a private server so that they could check it out on their own whenever they had time–even from their smartphones.

Issue: Automated test coverage is very low

CTO’s position My position
We work under very tight schedules: we don’t have time to spend writing tests. Tests make development faster, not slower. They don’t make you type code faster, but they make you think more about what you are typing, and they almost always force you to get it right the first time, so that the time spent later stepping through with the debugger is eliminated.
Some of our developers write tests; others don’t. We don’t enforce a rule; we’re most interested in having them do whatever makes them go fastest. What’s fastest is a Very High Test Coverage environment where everyone can instantly see all the effects of every change. It’s not faster if all you count is the time from when the source file is created to the moment the developer first checks it in as finished; but it’s significantly faster if you wait to stop the clock until it’s really finished, including all the bugfixes made necessary in the new code and in existing and future code it touches.
If you wait to write tests until after the code is already developed, then you know A) what needs testing, and B) how to test it. But I already know what needs testing even before I turn on the machine: everything. And I typically find it quite difficult and time-consuming to figure out how to write tests for code that’s already in existence, written without regard to testability, than I do to simply demand each bit of code into existence with a failing test. [Thanks to Justin Searls for that terminology.] That code is going to be more testable, therefore more accessible, therefore more loosely coupled, therefore better, therefore more understandable, therefore quicker to develop around and to refactor.
A mass of automated tests will make it painful and slow to refactor existing code. Quite the contrary: any significant refactoring of any significant chunk of code absolutely depends for its timely success on VHTC!  Without tests, you’ll be finding subtle bugs in your refactoring for months.  Refactoring is precisely where VHTC comes into its own and shows its real value.

Maybe the tests you’ve seen aren’t the kinds of tests I’m talking about.

Issue: Pairing is rare

CTO’s position My position
We pair occasionally, but we only pair senior developers with each other, and only under emergency circumstances, and generally for long periods–perhaps 12 hours. Hmm. Maybe you and I mean different things by “pairing.”

Issue: Change is expensive

CTO’s position My position
The way we’ve been doing it works for us, even if it outrages your sensibilities. We have a lot of happy customers and we’ve made a lot of money. We’re going to keep going in the direction we’re going at least for another year. Can’t argue with success. You’ll be fine as long as some hungry Agile startup competitor doesn’t come along and eat your lunch.
We’re not yet a big company. Agile would be pretty much completely new to us. It’d take us awhile to learn it; during that time our velocity would be lower, our customers would be less happy, and we would make less money, as well as having the added expense of courses or consultants or coaches or whatever we chose to train us. We can’t afford that now. Maybe after that year. Uh…that is…it’s…I mean…ah…

Sorry, I got nothin’.

Advertisements

Actions

Information

3 responses

14 10 2011
Eric Wilson

I think I used to work at this Arena district startup, with an unusually tall CTO. It was a great experience.

I’ve wondered myself whether full-blown agile makes sense for them. They don’t experience many of the pain points that drive bigger companies to agile, and they benefit substantially from the talent of the CTO in understanding business value for his clients.

Certain things are hardly disputable — consistent test coverage would be better. But other things are far less clear.

In any case, I think you did a good job presenting his arguments fairly. It would be interesting to see his recap of the argument, and in particular what he feels that he gained. I know that he is very passionate about delivering value to his customers, and he is constantly learning, and constantly improving his business.

14 10 2011
dnwiebe

Arena district yes, unusually tall CTO no.

14 10 2011
Eric Wilson

Oh, I think that I’m thinking of the right company, but the CTO title has been applied to a different man. So my comment makes a certain amount of sense, if one keeps in mind that by “CTO” I mean “founder” and if the last paragraph, which presumes insight into the man you were arguing with, is ignored.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: