The Expedient, Desirable Product

This is a guest post by Dorian Taylor, with whom I’ve been having a thought-provoking Twitter conversation about design. Here is an interesting pecha-kucha talk by Dorian that kinda explains where he’s coming from.

When I first en­coun­tered the phrase min­imum vi­able prod­uct, I thought to my­self here is a term that is ripe for mis­in­ter­pre­ta­tion by droves of hy­per­prag­matic un­der­grad-​aged startup founder­s with a cheque from Paul Gra­ham and more en­er­gy than sense. Ad­mit­tedly it’s an ap­pealing con­cept even if you don’t fall into that cat­e­gory, but it’s in my na­ture to take things apart and play with them.

My un­der­standing of the goal of the min­imum vi­able prod­uct is to ar­rive at something you can sell in as short a pe­riod as pos­si­ble. Its pur­pose is to get an­swer­s to em­pir­ical ques­tion­s that can only come from cus­tomer­s and users, while at the same time get­ting paid. Awe­some idea. Just a cou­ple of ques­tion­s:

What ex­actly is vi­able?

I’m going to use the def­i­ni­tion of a vi­able prod­uct as one that you can sell and even­tu­ally profit from. It’s worth noting that the ap­peal of soft­ware to cus­tomer­s is in­ex­tri­ca­bly con­nected to, but dis­tinct from de­sir­abil­ity, the ap­peal to users.

One of the first things a user ex­pe­ri­ence de­signer will point out is that cus­tomer­s and users are not nec­es­sar­ily the same peo­ple, such as with en­ter­prise or ed­u­ca­tional soft­ware. For a hosted app ven­dor, such as where MVP got its 15 min­utes, it’s the users who are often the cus­tomer­s, pri­mar­ily paying at­ten­tion, which I’m told is tan­ta­mount to paying money.

Whereas a con­ven­tional busi­ness has cus­tomer­s first and users sec­ond, a soft­ware com­pany, es­pe­cially a Web-​based soft­ware com­pany, has users first and cus­tomer­s sec­ond, due among other things to a pro­tracted pe­riod of trying-​be­fore-​buying — but I’m prob­a­bly not telling you anything new here, so moving right along.

If users have pri­macy, then the path to vi­a­bil­ity is through de­sir­abil­ity to have an on­go­ing re­la­tion­ship with the prod­uct, or at least glean sub­stan­tive value from its out­put. But the central em­pir­ical ques­tion that only your users can an­swer is indeed if they want to use the prod­uct, which they can only do by using it. Which makes sense if the prod­uct is novel. After all, you can’t do market re­search if the market doesn’t exist yet.

Soft­ware tends to ex­hib­it the fol­low­ing pat­tern: there’s a pit­tance of busi­ness logic, which is what you’re trying to test, sur­rounded by a pro­fu­sion of cladding that en­ables peo­ple to put it to work for them. The prob­lem I see here is that just about every pro­grammer I’ve ever met con­sid­er­s the lat­ter, at best, slightly less im­por­tant than the former.

While you may not yet know what is de­sir­able to users, you can prob­a­bly com­pose a de­cent list of what is un­de­sir­able. I’ll get you started: Non-​func­tion­ing UI el­e­ments, alert boxes, dummy text, stack dumps, data loss — just off the top of my head. Un­less your tar­get users are pa­tient de­vel­op­er­s, it might make sense to have your macro-​level im­ple­men­ta­tion pri­or­i­ties set by some­one who con­sid­er­s the prod­uct from the out­side in.

What counts as min­imum?

In Notes on the Syn­the­sis of Form, Christo­pher Alexander re­mark­s that while it is fairly easy to get con­sen­sus in a group on what con­sti­tutes a valid re­quire­ment, it is nearly im­pos­si­ble to get peo­ple to agree on their pri­or­ity. In fact, that en­tire book is all about res­cu­ing the generic de­sign pro­cess from the va­garies of human whim, bias and self-​con­scious­ness.

This is what orig­i­nally raised my eyebrows about the MVP: the thought of a room full of de­vel­op­er­s bick­er­ing over what work not to do. Ac­tu­ally, it’s more than a thought. It’s a com­pi­la­tion of far too many mem­o­ries.

If the goal of the MVP is to get sell­ing quickly, the fact that you can have a pro­tracted ar­gu­ment about whether or not a par­tic­u­lar unit of work is part of the min­imum set flies in its face. Often it’s faster just to do the work, min­imum or not. This isn’t just an issue for teams ei­ther, un­less you are im­mune to lying awake at night vac­il­lating over whether to work on one as­pect of a system or an­other, or do something else en­tire­ly.

This sit­u­a­tion is ex­ac­er­bated by the fact that a pro­grammer is ac­tu­ally an ex­ec­u­tive. That’s right: every line of code you write can be con­sid­ered your own ex­ec­u­tive mi­crode­ci­sion. While you may be get­ting told what re­sult­s are ex­pected, your ar­tic­u­la­tion of the so­lu­tion is going to be your own. You know this be­cause these de­ci­sion­s can turn out to be busi­ness-​crit­ical, and be­cause you in­vari­ably have the most in­for­ma­tion about what you are work­ing on. If this wasn’t the case, the per­son who did could prob­a­bly do a bet­ter job, and faster.

If, as an ex­ec­u­tive, you con­tra­vene your own bet­ter judg­ment, es­pe­cially at the be­hest of some­body else, ugly things start to happen. You lose trust in your work. You risk be­coming cyn­ical or ap­a­thetic from con­scious­ly pro­ceeding in a way you don’t sup­port. Your abil­ity to es­ti­mate goes out the window, as­suming it was ever there in the first place. And if the en­deav­our fails, the finger will prob­a­bly still be pointed at you. But even if it isn’t, you knew bet­ter but were com­plicit anyway.

So what­ever pu­ta­tively su­per­flu­ous ef­fort you value, you’re going to want to do it. You’ll sneak it in after hours; pull an all-​nighter if you have to. If you don’t, you’re going to ob­sess about it. If you’re a se­cu­rity nut, spend the time to san­i­tize your in­put­s or it’s going to drive you bonker­s. If the database is your thing, you’ll kick your­self every day you don’t prop­erly nor­mal­ize it. If you’re a stickler for code in­den­ta­tion, stop stew­ing over it and just fix it. Wor­rying about whether or not what you’re about to do is part of the min­imum set is cat­e­gor­i­cally a waste of time. If it’s ex­pe­di­ent, do it now.

As for be­haviour that is de­sir­able to users but not chal­lenging to pro­gram­mer­s, at least it’s easy. Let’s face it: bugs like the order in which but­ton­s ap­pear on a screen get triaged into orbit, so it’s eas­i­er on ev­ery­body just to get them right the first time, or as close to it as pos­si­ble.

Ex­pe­di­ent De­sir­able Prod­uct

There is valu­able work you can com­plete and de­liver today that is not part of the min­imum set. To con­firm its ab­sence from the set or to dis­cuss it with your col­leagues would take time, po­ten­tially more time than it would take to do the work. To omit it would de­prive the prod­uct of its value. Rather than argue about it, do the work and cap­i­tal­ize on it.

There is also work which is not on the main program but still valu­able: a tool, a doc­u­ment, record-​keep­ing, even tidying your work en­vi­ron­ment. Again, if you have all the means and the mo­ti­va­tion to com­plete it now, do it now. And if it pro­duces an ar­ti­fact you can sell, all the bet­ter. If you can’t sell it but it can aug­ment your col­leagues’ pro­duc­tiv­ity as well as yours, re­member to share it with them.

The ques­tion I ex­pect to be asked at this point is how do I de­liver a prod­uct on a dead­line with all these di­ver­sion­s? How do I pro­pose to keep a sched­ule if I’m con­stantly going off-​task? The an­swer is I don’t.

At least, I don’t in the con­ven­tional, Gant­t-​chart sense. Well-​un­der­stood de­liv­er­ables that re­sult from well-​trod­den pro­cess­es con­form nicely to a sched­ule, but how much of that are you re­ally doing? Your pro­duc­tiv­ity as a knowl­edge worker of any kind is pred­i­cated on your abil­ity to solve prob­lem­s, and that can’t happen with­out the right in­put­s. At the same time, you may ex­pe­ri­ence an eu­reka mo­ment with a dif­fer­ent prob­lem en­tire­ly, and it would be wise to cap­ture it while it’s hot. Some might call this pro­cras­ti­na­tion, but I pre­fer to think of it as op­por­tunism.

Be­sides, the only time you have to worry about being on-​task and on sched­ule is if you have some other kind of obli­ga­tion to which you’ve com­mit­ted. Oh, right.

That Whole Man­age­ment/Fi­nanc­ing Thing

The kind of deal we typ­i­cally strike in a busi­ness en­deav­our is to pro­duce Result X, such as the archety­pal MVP, by Date Y, which is rei­fied by a dol­lar fig­ure from a de­part­men­tal bud­get or a round of funding — a throw­back to the meth­od­s of man­u­fac­tur­ing or con­struc­tion. This is fine if you have solved the prob­lem al­ready and it only re­main­s to ex­e­cute it. But soft­ware is nearly al­ways novel by def­i­ni­tion, which means there are many un­known un­known­s and un­prece­dented de­ci­sion­s that will need to be weighed and ex­e­cuted.

Re­al­iz­ing modern soft­ware doesn’t nor­mally take big lump sums of cash. The cur­rency of soft­ware ac­qui­si­tion and sim­i­lar novel and com­plex prob­lem­s is con­tigu­ous block­s of time in which in­di­vid­u­al­s can con­cen­trate — lit­er­ally fetching dis­parate pieces of in­for­ma­tion from all over, or­ga­niz­ing them in one place and syn­the­siz­ing new in­for­ma­tion from them.

The rub is that in­for­ma­tion is in­fun­gi­ble. You can­not sub­sti­tute the bit that de­pict­s whether or not I like crème brulée for the one that in­di­cates my pref­er­ence for sea urchin any more than you can swap those in­gre­di­ents them­selves. Ac­quir­ing spe­cific bits of in­for­ma­tion takes a wildly ar­bi­trary pe­riod of time, es­pe­cially when you don’t yet even know you need to ac­quire them. And to echo the ad­mo­ni­tion­s of Fred Brook­s, your Result X won’t be achieved until you have the full com­ple­ment of rel­e­vant bits in your pos­ses­sion.

Note how­ever that this is not nec­es­sar­ily a long time, it’s ar­bi­trary. Finding a missing clue could take sec­ond­s, a life­time, or never occur. I’m told in the Real World™, how­ever, things need to get done, and that means com­pro­mise. But as we saw, how can we tell which com­pro­mis­es are cos­metic and can even­tu­ally be buffed out, and which will lie dor­mant only to crip­ple the prod­uct a year or two later?

And the pur­pose is what again? Time to market? So you can get a few more days, weeks or month­s on the front of the prod­uct’s lifes­pan in trade for po­ten­tially years on the rear? If, at the cost of your health, you went on a coding binge that made EA look civil in order to hero­ically power-​slide into the dead­line, you would cer­tainly have something when the dust set­tles. Why not shed the pre­tense that something is going to re­sem­ble Result X as orig­i­nally con­ceived, take your time, and re­lease something else in­stead?

When we focus too in­tently on Result X, we be­come blind to the no­tion that some piece of the in­tel­lec­tual cap­i­tal we gen­er­ate on a daily basis is bound to be within a degree or two of mer­chantabil­ity, which we can hand­ily have ready to ship today, let alone Date Y.

The con­ven­tional method of fi­nanc­ing and man­aging soft­ware, how­ever, ap­pears to be to say we want Result X by Date Y, here is the money to build it. The prob­lem is that there’s no build­ing going on. Once you have con­cen­trated the in­for­ma­tion rel­e­vant to the prob­lem and syn­the­sized a so­lu­tion you can ar­tic­u­late to suf­fi­cient pre­ci­sion, that’s it, you’re done. The code is writ­ten. If there’s any part of the method of pro­duc­tion shared by man­u­fac­tur­ing and con­struc­tion that soft­ware ac­qui­si­tion ac­tu­ally re­sem­bles, it’s the co­pi­ous re­search and plan­ning that hap­pen­s be­fore the cap­i­tal is al­lo­cated to build.

As an en­trepreneur, you could argue that a huge parcel of VC fi­nanc­ing is sure to see you to prof­itabil­ity, but the stakes on that bet are pret­ty high. It’d be harder to con­vince your­self of that on your Se­ries G round, as­suming you hadn’t got­ten the boot by then. But the task isn’t to build a fac­tory or launch a com­pre­hen­sive mar­ket­ing cam­paign or any of the other ex­pen­sive things you do with big cap­i­tal in­vest­ments. We’re talk­ing about keep­ing a small group of peo­ple off the street long enough to re­al­ize a prod­uct that will cover their ex­pens­es and then some, and from there they can take care of them­selves. Ar­bi­trary indeed, but prob­a­bly triv­ial. Once their prod­uct works, they can dock with the big-​cap­i­tal moth­er­ship for the means to make it scale (i.e. mar­ket­ing, sales, sup­port).

The micro-​VCs have the right idea about the scale of the in­vest­ment (and con­comi­tant eq­uity stake) but still ap­pear to cast the deal as an all-​or-​noth­ing con­struc­tion pro­ject. A prof­itable busi­ness can eas­ily pay some­body to just in­vent things all day, but I’m not sure how that would trans­late to eq­uity fi­nanc­ing. Pa­tron­age 2.0, per­hap­s? Might be worth a try.

Though if you’re con­tem­plating one of these ven­tures your­self, it’s a good chance you al­ready earn a great deal of money rel­a­tive to your time com­mit­ments. You could re­al­is­ti­cally slash your obli­ga­tion­s to se­quester as much con­tigu­ous time as you can to solve your prob­lem, and keep an eye out for op­por­tu­ni­ties to cap off old, un­fin­ished prob­lem­s, or to ex­e­cute those you’ve al­ready solved. They may come sooner than you ex­pect.

The Real Enemy is the Vac­u­um

Soft­ware is made of in­for­ma­tion and uses it as raw ma­te­ri­al, and we know that in­for­ma­tion can­not be sub­sti­tuted. A cer­tain quan­tity of it will indeed have to come from cus­tomer­s and users. Much more of it is avail­able from nu­mer­ous other sources that do not re­quire promising a prod­uct. A sur­prising amount is lying around close by, in varying de­grees of con­spicu­ity.

The most im­por­tant factor for keep­ing the pace of a soft­ware or indeed any other cre­ative or prob­lem-​solving en­deav­our seems to be to get spe­cific an­swer­s as quickly as pos­si­ble. With that the ra­tio­nale be­hind the MVP is clear.

Though we may do our best to fa­cil­i­tate the in­bound flow of in­for­ma­tion, there will in­vari­ably be ser­vice in­ter­rup­tion­s. When we are fo­cused and com­mit­ted to a sin­gle ob­jec­tive, this short­fall of in­for­ma­tion poses a quandary when it comes time to make a de­ci­sion, in which we ei­ther vac­il­late or commit to a sub­op­timal so­lu­tion.

It’s hard to say which is more haz­ardous, no de­ci­sion or an ar­bi­trary one. I re­call a Teddy Roo­sevelt quote re­cently co-​opted by some Agile evan­ge­list or other: In any mo­ment of de­ci­sion the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is noth­ing. Ral­lying words for the early 20th cen­tury, when the keystroke wasn’t quite as po­tent.

When a vac­u­um forms around one ob­jec­tive, we would do well with the dis­ci­pline, freedom and sup­port to switch to an­other. After all, who re­ally cares, hon­estly, what you work on, as long as you de­liver something?

Your cus­tomer­s or users?
Not if you don’t promise them anything spe­cific.
Your in­vestors or em­ploy­er­s?
Not if you’re busy mak­ing them rich.

Get Ribbonfarm in your inbox

Get new post updates by email

New post updates are sent out once a week

About Venkatesh Rao

Venkat is the founder and editor-in-chief of ribbonfarm. Follow him on Twitter


  1. Dorian: I think you are critiquing more than MVP. You are critiquing the notion of goals and outcome descriptions entirely. This, I whole-heartedly agree with. Also, great Glengarry Glen Ross ref :)

    If you don’t really have a clue what’s hard and what’s not in getting a product vision implemented (true if you are trying to pull of a truly innovative concept), without trying to actually do it, then getting married to a product vision is stupid because you may realize at the end that you’ve won a Pyrrhic victory: the shortest, cheapest path to that vision might still be “not worth it.” The product should be “whatever useful place you can get to cheaply, with the most bang for your development bucks.” If in following this philosophy, your next generation tax planning software ends up as a 3D game, so be it. That said, this process needs to be conscious, and the customer development process needs to track and even run ahead of it a bit, or you’ll be trying to sell 3D games to people looking for tax software.

    So yes, in that case, I am a big believer in expediency. I’d state it as “build whatever you discover seems most valuable.” And valuable here is in terms of the leverage of effort.

    That said, though goals (and goal set) features are not completely controllable, the degree of influence of user feedback IS. Here, the ideas of controllability and observability from systems and control theory is valuable. If a bit of work is never (or rarely) observable in the UX and/or cannot be meaningfully impacted by anything the user does, putting in too much effort there simply because it scratches a personal itch, is not justified. Fortunately, most good product builders (s/w or h/w) usually end up with itches that DO impact the UX, even if only for a very small class of users for a very small, but important proportion of their time. The priority computation becomes very easy if it is mainly about probability and magnitude adjusted UX impact. Input sanitation doesn’t affect 99% of users, but does affect hackers, so it is worth paying attention to, since a security hole COULD mess up the UX for all 100% with a nonzero probability. Ditto things like scaling and load-balancing work. Not observable in the UX under normal circumstances, but if you ever get that nice-to-have spike of traffic, 100% of users will be impacted (which may actually be 1000% with respect to the pre-spike base). Even apparently user-unrelated features like a good admin panel for the product team, matter, because if that doesn’t exist, response time when things break skyrockets, impacting the affected users.

    All that said, there is something of real value in the MVP idea that I think we might be missing here. Eric Ries’ truly extreme examples, like running an AdWords campaign pointing towards a vaporware page… I think that’s a brilliant idea. Maybe it ought to be called “desirability testing” or something, instead of MVP.


  2. First, thanks Venkat for airing this post.

    I guess the thing I was really trying to capture was that software, to me at least, is really crystallized method. The code I write is my articulation of my opinion of how a certain problem ought to be solved.

    But a product, even a tiny one, is still a really big problem. And I’m almost completely convinced that you can’t have an opinion of a method for solving a problem you can’t at least circumscribe if not fully, deeply, intrinsically understand it (grok, as Heinlein intended). Once you have the problem fenced off, you can start mapping out its innards.

    If you can’t circumscribe the whole problem (but somebody has to, that’s pretty much conceptual integrity defined) you at least have to circumscribe your part of it, certainly before you start promising delivery dates. Otherwise you get mud.

    Within that process, though, arises this anatomy of fenced-off problems and corresponding solutions. These problems almost certainly generalize and thus their solutions will almost certainly have different applications that could be put to use right away.

    Furthermore, when I look at my own stash of IC, I have more stuff lying around than I could even realistically find or identify. If I had organized my work as a mapping of discrete problems and solutions, I would probably be doing much less duplicate effort and more importantly putting more of it to economic use. It’s also worth noting that these units are fundamentally smaller than the conventional notion of a product. Take Ted Nelson or Doug Engelbart’s attitude with respect to files as a basic unit of data storage and apply that to business deliverables.

    I chose input sanitation as an example of quasi-superfluous effort because in my experience it is much more likely that you are going to incur a failure due to malformed input (especially in a client-server model) than malice. Therefore if you took the time to do it, you could troubleshoot much quicker, and it would be orders of magnitude cheaper to clean up.

    I’ll give you an example: I worked somewhere that dealt with customers in 15 languages and the desktop client developers didn’t normalize the encoding on their client so data was entered in whatever native character set the user’s computer was set to. The result was an Oracle database full of years of UGC that was illegible and we (er, I) had to clean it up. While I have a black belt in charset-fu, a significant portion of it was unrecoverable and it wasn’t like we could go knocking on thousands of users’ doors to ask them in whatever language we think they’re speaking to please reenter their data. In that case we’re talking about a fix that would maybe take a few minutes on the inside and on the outside a day, and who knows what the total cost was of not doing it. It’s safe to say that the client developers didn’t take character sets into account but if I was in charge of that team and and consciously struck that from the to-do list, I’d feel like a bit of a (soon-to-be justifiably unemployed) knob.

    Ries’ method of buying AdWords as a way of soliciting votes for a product is pretty innovative. Only I wonder how it scales. I can see it being effective if the message is “would you like an X that does Y?”, where X is something familiar and Y is something new, but I’d wager it wouldn’t work for something totally alien. Maybe he’ll show up and can chime in on that.

    Also, this is 2010. I mean come on, doing your taxes should be like playing Tetris.

  3. Often it’s faster just to do the work, minimum or not.

    Yes indeed!
    Reminds me of days of yore (1980’s personal anecdote), being a consultant on medium sized project ($8m) I once asked for a fairly simple change in the specs, a given timeout had to be increased from 100ms to 200ms, covering two sampling cycles instead of one.
    Instant bickering response from various contractors, that’s a MAJOR change, we could never have expected that, this needs a contract addendum, more money, more delay and blah, blah, blah and several ensuing meetings with tech people, legal people and project managers of the involved subsystems (there were some hardware and multiple software components) lasting for hours with a lot of highly expensive people, including me.
    As a representative of the project owner, though, I had some ways of retorsion and all finally caved to implement the change.
    It happened that I personally knew the developer in charge of the piece of code to be amended and asked him:
    – How long did it take you to make the change?
    – Oh, about half an hour…

  4. It seems that this article also touches on Ward Cunningham’s notion of “technical debt”. This metaphor is a nice way to explain to a client the importance of doing it right, and gives you a business case to address it (ie. that the debt will gain interest and you will have to pay it off in the future).

    • Yes, that certainly seems to belong in this discussion somehow. I only heard about the tech debt concept last year, and though I haven’t properly wrapped my mind around it, it seems like a very useful one. In a sense, it is an operationalization of Knuth’s old saw about ‘premature optimization is the root of all evil.’ Tech debt is the punishment/burden of that necessary evil.

      I used to think the tech debt effects are bigger in manufacturing than in software (eg. design changes after the assembly line tooling is complete, and inventories have been stocked up and the first production run is underway). But now I am starting to believe that for complex software, the tech debt effect can exceed the hardware manufacturing cases.


  5. Sam Penrose says

    Technical debt can bedevil you in non-obvious ways. Any non-trivial amount of technical debt is difficult for the developer who “charged” it to measure, and more difficult for most others. Worse, the cost can explode (the developer who “charged” it left just before the performance hit it embodied became catastrophic, and the new developer doesn’t understand his code after reading through it 5 times) or even evaporate (the company abandons the product that uses the code).

  6. Good point. One person’s technical debt is another’s irreversible technical entropy!


  7. The main comment I have on the notion of technical debt is that it isn’t exclusively technical. It is at least as much about politics within and between business entities, and likewise about economics.

    We can understand any segment of code as being a reflection of how its author understands the problem, and his or her capability to express it. It also reflects the amount of attention the author is willing or politically able to devote. Likewise, some decisions that contravene the author’s best judgments get handed down arbitrarily by authority, cultural norm (e.g. a “Java/MS/LAMP/whatever shop”) or just by default.

    This, of course, happens all the way up the stack, which manifests as the entropy of which you speak. From what little I understand of physics, any reduction in entropy in one place merely creates it in another. With information entropy, however, we seem to be able to generate it in geometric proportions. Merely moving it around is about the best we can hope to do. More importantly, a lot of the entropy is completely unnecessary, but just like real debt it comes from a perceived scarcity of resources in the short term to understand and express, that is to characterize, the problems that we’re trying to solve.

    This is part of the reason I’m skeptical about many of the Agile practices, because while they have the right idea about responding to reality instead of trying to prescribe it, they still have a tendency to cast conceptual problems as those of technical implementation. While I acknowledge there is plenty of information you can’t get without empirical research and experimentation, I think the allure is often too great to try to incorporate the (executable) results of those experiments into the final product, and that is a huge source of entropy right there. In the past I have advocated strict policies around disposing prototypes, even intentionally prototyping in languages other than the one you intend to ship.

    The ability to cheaply implement something right away is almost always a siren song. Especially if you ship it, because that is at least a tacit if not explicit promise to customers and users to deliver some kind of utility, and a star-burst BETA badge isn’t an especially adequate disclaimer. The principal failure mode I’ve observed with respect to any process intended to acquire a technology is that it gets oversold by sales and marketing and reverts to a death march, usually with the help of the developers, whether they are aware of it or not.

    There is one reality that any software development process, including the Agile ones, still attempt to prescribe, and that is when the product is going to be delivered. This is part of my inspiration for the expedient desirable product. The problem, to me, with attempting to prescribe a schedule of any kind when it comes to any sufficiently novel endeavour is that it does not account for the fact that it reduces to individual people gaining comprehension of a set of concepts and how they interact with one another and then articulating that in preferably some concrete form. But information is infungible, and you can’t predict when or how you are going to acquire any particular piece of it. But one thing is certain, you won’t succeed until you acquire the information you need to continue, or find yourself a bagholder. I think we see way too much of the latter, frankly.

    Despite all this, I know that if I sit down for a few hours in front of a computer, I’m very likely to create something of value. As long as the little red record light is on, even data gathered from a Web-surfing expedition (right Venkat? ;) can be useful in abridging the uptake of the same body of knowledge for somebody else. At least half of my work is learning new stuff. I’m also pretty confident about the amount of time to devote at once.

    I may not be able to prognosticate when a certain problem is going to be solved, but I can count how much it costs to purchase four hours of a creative professional’s attention, and I can likewise observe what he or she generates, as it is added to an inventory of understanding. I can also recombine the contents of that inventory to create more sophisticated results, and recursively feed them back in. So the value of any individual’s half-day stint is completely arbitrary, as is the net value of his or her contribution. Likewise, this process of technology and product acquisition is not linear and continuous, but discrete, recursive, and ultimately fractal.

  8. @Dorian Taylor

    Cool down, all this philosophy is useless.
    As a 63 old retired software engineer I can tell you, software development is a mess, has always been and will always be.
    On any project you have 3 constraints, functionality, schedule and budget, you can control any two of them but not all 3.
    Happy exceptions are just that: a stroke of luck due to chance circumstances.

  9. @jld,

    Philosophy is useless if and only if you’re sure about what you’re doing. If you don’t have that, your project triangle is irrelevant. In my (albeit limited, 31-year-old, retired software engineer) experience, engineering is what you do when you know what to do. Every single project I’ve ever worked on, the main challenge has been to establish exactly that.

    Thanks for your comment.

  10. Every single project I’ve ever worked on, the main challenge has been to establish exactly that.

    Yes, your experience is right on!
    The trouble isn’t mainly technical it comes from the clients, they don’t know what they want even less so what they really need, you have to outguess them.
    With a bit of skill it may work.
    For the anecdote, I was working in Belgium for a medium sized company when they introduced the VAT.
    I went to the head of accounting who, strangely enough, was overseeing IT and told him: from now on you better record the tax rates for every item sold.
    Response: All that shitty tax business has nothing to do with “real” accounting, I don’t want to see anything about VAT in my accounting files.
    Fortunately, at least for invoicing, the tax rates had to be entered for each item, so I managed to store them in a “hidden” file which would never show up on any report or “official” file list.
    Surprise, surprise, by the end of the year the fiscal administration required various detailed sales reports per tax rate.
    Too bad, the accountants would have to reprocess all sales inputs for the whole year in order to sort sales amounts per tax rate.
    After the heat built up a bit I suggested a miracle solution to come up with the desired data without ever explaining about the hidden file.

  11. Per your anecdote, it’s most accurate to say that I’m completely uninterested in doing business that way. Furthermore I believe there are other ways to do this kind of business. Much of what I’ve been about for the last few years has been to find ways to achieve complex goals without incurring an all-or-nothing risk. In short I refuse to guess and especially to outguess anybody about anything.

    What I found, however, was that all-or-nothing risk is inescapable. What I can do, though, is bash one big risk into a number of very small ones. The whole idea about an expedient desirable product, which is an intentional play on Eric Ries’ minimum viable product, is that it is what one person or a small group can deliver in a single business day. But it’s important to recognize that I’m not talking about delivering software in a day, not specifically. I’m talking about creating a feedback loop in which many kinds of artifacts can accumulate and be recombined with one another in successive levels of complexity. This extends the conventional product calculus by a dimension, such that I can achieve fast, cheap and good all at once, but I can’t say what I’m going to end up with at the end of the day.

    I recognize, and I believe I accounted for, the fact that this turns conventional project management and likewise product marketing, fiscal behaviour and financing methods upside down. The other contention I hear often is that if you don’t apply a priori constraints on time and resources, the project will never get done. Consider me jaded, but I have experienced way too many projects that did operate under significant resource constraints, and they never got done. This is why I have gone in search of an alternative.

    Possibly the most important thing I realized was that the conventional notions of product and project are just deals. Between people. There is no physical law that ordains how they ought to be laid out, with one possible exception: complex objects decompose into sets of simple objects, and complex processes decompose into series of simple processes. But it is important to recognize that their respective scopes are finite. This means that we don’t have to worry about doneness, because it is built in.

    The deal we are used to is to add up the cost of materials, work out how many people it will take over how long, and tender a bid (or in the case of startups, a business plan). I submit that anything that can be called an engineering project is about the upper bound of complexity for which this model works. Building: start at the bottom, end at the top. Railroad: start here, end there. Freighter: start with the hull, end with the bridge. Et cetera.

    I can say two things about this category of project: First, they have an explicit orientation, and that progress is readily observable by stakeholders. They have a bottom/top/back/front/whatever. Post-industrial projects do not. The second, which actually applies to all projects, is that a dearth of working materials will choke them. Industrial projects use commodities as materials: steel, concrete, wood. These are fungible. If one source dries up there is a good chance you can find another. Post-industrial projects use information as material. This is infungible. Even so much as a single bit of a critical decision missing can choke a project. This I have witnessed numerous times, and it blows all hope of a rational, sequential decomposition of tasks and division of labour out of the water.

    A way I see to get around this infungibility of information is to work on whatever is present and handy at the time. The cost of fetching new information is arbitrary, so I might as well not put myself on the hook to deliver something that depends on the timely sourcing a material that is so wild in character.

    What I am suggesting is precisely to change the deal from the delivery of a monolith of arbitrary complexity for a best-guess cost, to the delivery of a generator of useful material which uses its own produce as fuel, and of which a fraction will be viable.

    I should also note that I had zero intention of becoming a philosopher, and I chuckle every time I’m compared to one. I’m really honestly just looking for a practical way to carry on with my craft without screwing myself.

  12. the delivery of a generator of useful material which uses its own produce as fuel


  13. I think I saw something move under that bridge over there.

  14. The point of MVP is not time to “market” as in winning a race or getting profitable, it’s time to “finding out whether your idea is marketable or not”. The biggest technical debt is spending extra time refining a product which nobody wants (hellooo OSAF Chandler). Which, in my experience, is the most-likely outcome in software startups.

    Also, I don’t think the MVP-police will lock you up if you spend some time doing something that isn’t obviously M. It’s a vision/direction rather than a binary, at least in my mind.