Date: Sat, 15 May 1999 22:37:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: davids@webmaster.com (David Schwartz) Cc: chuckr@picnic.mat.net, chat@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <199905152237.PAA03142@usr07.primenet.com> In-Reply-To: <000a01be9d6c$b4dffec0$021d85d1@whenever.youwant.to> from "David Schwartz" at May 13, 99 11:16:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
First off: David, tabstops are 8 characters! Lines formatted like: xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx Are unreadable, especially when you don't limit yourself to 72 characters, and the lines wrap. OK, that out of the way... > > OK. Much of what I'm going to say here is pure opinion, understand; I > > don't hold it forth as fact (like I did the top paragraph). The > > situation that I *think* you want, where the users do the controlling, > > doesn't now and never did exist. I've worked for enough companies to > > know that you code for your boss, not the public, and what the boss > > wants very often has nearly nothing at all to do with that which the > > public is clamoring for. There are isolated cases where the connection > > between want and need is closer, but it's not the rule. > > > > My, that sound cynical. > > No, it sounds silly. In an organized project, someone makes the decision > about which ideas turn into code and which don't. The extent to which that > decision is or is not distributed varies. Almost always some such capacity > remains with the programmers. My personal experience in both free and commercial work meshes with Chuck's experience. I will go further than he did, however: it is infrequent that anyone can do anything revolutionary unless they are a part of a small team working in isolation, and they control all aspects of their project. At its absolute best, "the masses" get what they need, which may or may not be what they want. At its absolute worst, you burn several million investor dollars and several years of your and the other people in it with you's lives, for no gain. A free project is driven by what people are willing to code, and by what the people with the keys to the source tree are willing to commit. A commercial concern is driven by money, and by what they believe people are willing to buy. You are very lucky if the people at the very top are driven by something other than closing in on their exit strategy. They are almost never driven by vision, and if they are, they are generally ousted by the risk adverse among the investors. The gating success factors for companies are vision, process, and the 800 pound gorilla. Success is defined in terms of ROI. If a company is driven by a talented 800 pound gorilla, it can be successful, as measured by income. Steve Jobs is a good example of a talented 800 pound gorilla. In general, however, gorillas can only beat up so many people at a time, and companies which depend upon the gorilla do not scale above 12 to 16 employees. A talented 800 pound gorilla can only keep his thumbs in 12 to 16 pies at a time. A smart 800 pound gorilla (like Jobs) will delegate the micromanagement to his trusted lieutenants, and then will personally micromanage only the lieutenants. This results in crisis management policies, otherwise known as "the squeaky wheel gets the grease". If a company is driven by a well engineered process, then the process is the product. USL is a company like this (or was; I have no idea what effect SCO has had on it; I know Novell had none), where it is more important to follow the process than it is to do any other job task. That said, a company can design a process without it becoming the product, and which will produce results: you turn the crank, out come the results. Such a company is a machine, and can be successful at tasks where precision is important. Many military and aerospace contractors are drive by well engineered process, without the folly of the process becoming the product. The folly, however, is a very seductive trap. If a company is driven by a well articulated vision, then it is also capable of being successful. A well articulated vision is one which everyone understands, and on which everyone agrees. The well articulated vision serves the employes as a litmus test. For every set of options, they can hold up the vision, examine it, and choose the option that is right for the company. However, a well articulated will not cause you to, for example, set up a CVS tree instead of writing production code; the danger is one of becoming shortsighted, and focussing on short term objectives. Focus is no substitute for vision. Each of these models has the capablity of being successful, and each has its (very seductive) traps. In general, I would say that the 800 pound gorilla model is OK for a startup, but when you hit the scaling barrier for your particular gorilla, you need to eject it, and put in a general manager in its place. Failure to do this will result in tiered crisis management begoming rampant. Such organizations can be recognized by their non-flat architecture. That said, the traditional American "lift yourself up by your bootstraps" model in general, and the Silicon Valley Entrepneurial Venture Funding model, in particular, depend upon seeing a gorilla. This is, IMO, why so many S.V. startups fail: inability to scale. You can't grow beyond the ability of your gorilla to micromanage. I believe some process is necessary. For example, a process whereby an engineer is asked to make time commitments based on functional requirements, and then there is no negotiation permitted for any additional time for productization requirements, is fundamentally flawed; it neglects the necessary negotiation which allows the total time cost to be considered in the equation for the total of both the functional and productization times, per feature. Such processes tend to come about as the result of crisis management; not surprisingly, this is, IMO, why so many S.V. startups so rarely meet their ship dates for products. I believe vision is paramount. I personally will not work at a company without vision, or on a project without vision. The vision must be both clearly articulated, and universally interpreted (mostly due to the clarity of the articulation), if the company is to be successful. Vision is a quality that is antithetical to the 800 pound gorilla. A company with vision knows what the future will look like, and intends to get there "come hell or high water", and God help those who get in the way. But having a vision is not enough. There must be a roadmap, a decree of "how we get there from here". If there isn't, then it's very hard to decide what the next step should be. A company can't look ten years ahead, and actually get there, unless it knows what's 6 weeks ahead in that direction, or what products are along the road to keep it going. In general, we come back to the S.V. issue of crisis management: deal only with that which is in front of you. It is a corruptor of vision, which replaces it with a poor substitute: focus. This is, IMO, why you always hear Dilbertesque phrases, like "let's focus on getting the release out", or "we need to put all the wood behind one arrow", or "we need to all row in one direction" out of S.V. startups. These startups frequently fail as a result of stumbling around blindly, for lack of vision. Feel free to draw what parallels you will between these categories and free software projects. > There are many ways and reasons a project can fail. Code dictates that have > little to do with 'customer' demand is a common one. But it's just as > possible to fail because programmers code things that customers don't > demand. This isn't true, at least not for companies. For a company, doing engineering of any low level short of outright fraud can make success possible. Sales are driven by marketing, not engineering. In fact, I would say that the value engineering has is only in terms of _repeat customers_, not _inital customers_. The amount of effort that a company puts into engineering is irrelevent, if there are no initial customers to prime the pump. There are generally two ways to cash in on good engineering, both having to do repetition. The first is _repeat sales_, where you sell another of the same product into the customer, and the second is _the customer relationship_, where you make a sell of a different product into the customer, based on their satisfaction with the initial product. Companies with perishable/consumable products must manage the ongoing customer relationship to encourage repeat sales. Companmies with product lines must manage the ongoing customer relationship to promote horizontal ownership of the customers patronage. Note the important yet subtle conclusion this forces: if you want repeat customers, you have to give the customer what they need, even if it isn't what they want. Long term satisfaction builds the relationship. On the other hand, if you want repeat sales, then you have to give the customer what they want, even if it isn't what they need (how many nutritionally balanced fast food places are in your neighborhood?). Where does this leave one product companies? Well, if they are smart, it leaves them giving the customer what they need, but at the same time satisfying the want, right? Wrong. A company needs to decide whether they are going to be a repeat sales company, or a repeat customer company, and commit to the course. Otherwise, they are blindly groping themselves in an attempt to give the customer both what they want AND what they need, and these sets are almost entirely mutually exclusive, to one degree or another. And the failure to commit to a course of action is, IMO, the reason so many S.V. companies just dwindle away in their first year, without making a mark on the world. > The big issue is, when you are dealing with a non-commercial project, > what is your definition of 'fail'? What, indeed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905152237.PAA03142>