Continuations
Latest Comments
Reply | Original | Permalink | Share | TweetI'll rephrase a bit my last sentence...
For the high echelons of governing - in all spheres (government, business, nonprofit) - the culture and spirit of "public service" should prevail as primary motivation over material compensation.
Someone was lamenting recently the potential loss of "smart" Wall Street people to places like Dubai and Russia in case we slash their compensation. What a ridiculous thought! First, let them go and do their thing there too... this may give us (the US) a strategic competitive advantage. And second, it is stupid to think that the best people in business work for the money only. I would never "lure" (as they say) executives with huge compensation. If they are not motivated by the public "cause" (raison d'être) of the company - I wouldn't be interested in them - period.
Reply | Original | Permalink | Share | TweetTotally agree... "second secularism"... really good analogy to work from.
One thing I still can't understand - we rightly see Blagoevich as "disgusting" when he puts a price tag on his political decision making - but we still don't see nothing wrong in elevating material compensation as the primary (not to say the only) motivation for CEOs of big public companies to do their job.
Executive careers in PUBLIC companies should be seen as public service. Money shouldn't be the primary reason to be in these careers.
May be America should stop centering its social mythology around stuff like "anybody-can-get-super-rich" and the glorifying of the nouveau-riche mentality. We've had that for some time already.
Don't we have enough young people in this country for whom material compensation is practically not relevant simply because their parents and grand parents already took care of this.
The urge to make even more money (after you already have a lot) - to me - is a sign of cultural and intellectual immaturity.
Public service should be THE "elite" thing to do in this country - above and beyond the "getting rich" thing.
Reply | Original | Permalink | Share | TweetYes -- we need a renewal of public service as the thing folks aspire to do (instead of aspiring to become ultra-rich). Don't think it's necessary though to have public service be the motivation for the folks running "public" companies. Instead we should have the boards of public companies be elected more directly by the shareholders -- as happens with many venture backed companies -- so that boards are not packed with appointments made by the CEO.
Reply | Original | Permalink | Share | TweetAgreed. Great posts btw. Good early morning read with the cocoa krispies :)
Reply | Original | Permalink | Share | TweetIt's a start, but it is more of a seed fund with a return motive. Not the same signal as if Bloomberg made some angel investments himself.
Reply | Original | Permalink | Share | TweetBloomberg rolled this fund out ... don't think he is a part of it though. http://mashable.com/2008/06/02/nycseed/
Reply | Original | Permalink | Share | TweetDefinitely a big factor. But could also be that you are really young and don't have a lot of financial obligations yet.
Reply | Original | Permalink | Share | TweetOnce you have achieved some degree of personal financial stability (may be after a successful first venture... or simply because you always had it), you could... and probably should... be bolder... and go "transformational" more often.
Reply | Original | Permalink | Share | TweetLooks like an interesting book. We have a ton of data and decision problems in our portfolio companies. Would enjoy a discussion some time.
Reply | Original | Permalink | Share | TweetPosted a response
http://jtonedm.com/2008/12/10/its-not-ai-but/
Reply | Original | Permalink | Share | Tweet"Dollars that flow into the economy through government purchases stimulate demand directly." Perfect Keynesian policy, If I remember correctly. Through its purchasing power the federal government can do so much to influence where private investments are made. Cleantech is an obvious area for this as is agriculture.
Reply | Original | Permalink | Share | TweetThanks. There will definitely be a couple more posts.
Reply | Original | Permalink | Share | TweetNice series. Will it continue beyond today (12.2.2008)? -brenda
Reply | Original | Permalink | Share | TweetYou should absolutely buy all your other presents for everybody else at http://etsy.com
Reply | Original | Permalink | Share | TweetBut if anyone does want to buy Albert anything, even after reading this, please buy it at www.etsy.com I think he would approve.....
Reply | Original | Permalink | Share | TweetThe inventory as feature/requirements/unreleased code analogy definitely resonates with me. I also wonder as more and more software companies use cloud computing for their storage and processing that they will naturally need to focus much more on nailing the requirements/coding/testing efficiencies rather than hardware.
Reply | Original | Permalink | Share | TweetMike - totally agree that "premature optimization" is a bad idea. Building a scalable machinery before you need it is a waste of resources. Very few companies fail over scaling. Most fail by not getting traction. But once things take off and you do add features there will be a big difference between doing so in a way that makes adding more features in the future easier or piles on cruft.
Reply | Original | Permalink | Share | Tweeta related concept that comes to mind is "technology debt", i.e. the cruft and inefficiencies that build when you take development shortcuts over time, and the corresponding time it'll take to fix them.
Reply | Original | Permalink | Share | TweetI posted some similar thoughts about Twitter when everyone was wailing about their downtime and terrible architecture. Twitter is still here, and they're slowly draining the lake, just enough to remain viable.
Reply | Original | Permalink | Share | TweetI guess I'm coming at it from a startup founder point-of-view. This assumes you have the luxury of time on your side, the time for the refactoring to pay off. I actually have some personal experience with this. In our company we spent an inordinate amount of time on being "smart" and efficient with our code and code architecture. While we had an elegant and efficient back end, we failed to generate the large number of users that would have really had the efficient architecture pay off. So I chalk that up as a major early failure on our part for not letting the system be "crappy but just good enough" and focus on actually generating the features and interest first and then worry about dealing with code inefficiencies at a later date.
Our new product we're ignoring almost all refactoring and efficiency efforts until absolutely necessary. It may be we're swinging between extremes, but so far I feel like we're off to a better start on this one than our previous effort, even though the lake is full of bodies at the moment. :)
Reply | Original | Permalink | Share | TweetThat is exactly where traditional manufacturing optimization in the OR tradition and lean manufacturing / Kaizen differ. The traditional approach suggests that thee is an otimal inventory level because reducing inventory too much would require too many optimizations. That is the suggestion that some hardware slack is permissible if it means that you spend more time on features. Lean / Kaizen says that the long run benefits from super aggressive refactoring
Will far outweigh any short run feature benefits. The idea being that you will continue to be able to add features
In the future.
Reply | Original | Permalink | Share | TweetI think the analogy is flawed somewhat and can't be split that easily. You're assuming there is a simple tradeoff between efficient code and more hardware. That's missing a relatively large part of the equation. Analyzing and refactoring code requires significant effort and focus. That in and of itself has it's own associated development costs, but there's an even bigger cost, the opportunity cost of what *could* the software developers have been working on if they *weren't* re-factoring for efficiency? So weigh those costs vs. the cost of running on more hardware (which becomes cheaper all the time) and you see there is a reason to ignore "the bodies". Any software company worth its salt *knows* there are bodies lurking in the lake, they just know that it's best to assume they'll get to them later when they start to become a problem.
Most software companies know they have to drain the lake a bit, but just enough to build the bridge they need to get across. Find the balance that lets you get what you need done without incurring the cost of draining an entire lake. :)
Reply | Original | Permalink | Share | TweetNivi - thanks for the great comment. You are right that is a much more direct analogy for the inventory concept. I will look at the links.
Reply | Original | Permalink | Share | TweetThat's an interesting idea that I will think about.
Conventionally, hardware isn't the typical source of inventory in software development.
Inventory is anything that isn't being pulled by something further up the line. In software development, inventory is features that can’t ship because they’re buggy. Code that isn’t in customer hands. Architectures that aren’t coded. Requirements that aren’t coded, shipped, and useful. Most to-do lists.
Here are some resources to learn more about lean thinking in software development:
Implementing Lean Software Development
http://venturehacks.com/topics/lean
http://startuplessonslearned.blogspot.com/searc...
Let me know what you think and I'm looking forward to reading the rest of your series.
Reply | Original | Permalink | Share | TweetI think you will be surprised to see the many analogies. I am really excited about writing this series of posts.
