INTERESTING DEVELOPMENT TEAM AND PROCESS (cultural observations) (transparency i

INTERESTING DEVELOPMENT TEAM AND PROCESS

(cultural observations) (transparency into the process)

The standard dev model that we practice in Seattle, and in san francisco isn’t followed here in Kiev. It’s partly cultural, in that males here are ‘different’ in their trust, expectation, and collaboration methods. Its partly that most of the development here is support, web, and ‘do it cheap’ work. So no matter who you talk to, almost everyone sounds like a 1999 tech boom developer.

So, you can’t sort of hire people and expect them to have the full suite of product developer skills and habits.

Second, I’ve learned a lot over the years, partly at Microsoft, and that is to produce a feature complete product, and then refine it. The reason for this is that most product management and technology people in most organizations try to overly simplify the software. And I didn’t want that. The web only exacerbated this problem, and so did the apple and iPhone design ethic. Microsoft has taken it too far, in that they have thrown the kitchen sink into their products. But we are trying to develop something very special (the full impact of which will take another year of work to be visible). And I need a rich desktop level of application written for the web, with rich features.

I am perfectly happy throwing away code if I’m going to produce something better. And so I prefer low investment up front, and then to harden later. If you know what you want to build, and you’re clear abou tit, then you can work with high up front investment. But I can’t do that because we’re engaged in research and development, and so we must buy experimentation cheaply.

So, we sort of work like this:

1) I have this enormous list of features.

2) Starting from the foundation on the back end we have built from the back to the front, and are now building from the front user experience and modifying that back end.

3) I make a list of features we need to work on, make the drawings, fill out an excel spreadsheet, and work with Denis on the general design. It is very loose. If there are any strategic questions we round-table them and get everyone’s interest and criticism.

4) Denis implements the user interface, improves the design and finds all the holes in it. Then we debate back and forth. I want a rich desktop interface that i can sell. Denis is always trying to minimize the information density and produce something reasonably clean.

5) Vitalii refines the UI and makes al the complex JS work.

6) Kirill integrates the back end, because he basically ‘owns’ the core engines: Organizational Dimension System, Workflow, Messaging, Currencies, and the Database.

7) Heavy lifting (stuff that has to be ‘right’) and performance is done by Alex.

8) Then I do the testing and bug reporting.

9) Then they all divvy up the bugs and changes I put through and do the work at their discretion.

It took a while but it’s a pretty good workflow. It’s not anything like ‘feature teams’ that I’ve generally used. It’s totally organic. And it works.

But, since we are done with the R&D phase, and have our model figured out, soon I’ll have to basically double or more, the size of the staff, and harden the application rather than conduct R&D. And that means more than doubling the burn rate.

I’d originally planned to spend all of my own money, but the government’s latest torture of me has changed that, and I’m going to pull in some early money.

Given that I expect no less than 10x, I’m pretty sure that’s an easy raise.

(Thanks for listening. Apparently people like this ‘working in public’ thing, like watching pre-industrial silversmiths, cobblers, and potters constructing their wares in open shops. I wish more people did this. It promotes honesty. And we all can learn from each other.)

Curt