The Rise of Developeronomics
forbes.com
forbes.com
I don't think this is true right now; I very much doubt it will ever be true.
I live within walking distance of not less than five excellent boulangeries and have never used any sort of "social" tool or other technology to select the one I'm going to buy bread from. I try them all regularly, know what they do well or less well (one is better at croissants than the others) and basically go to the one that offers the best version of the product I'm looking for.
Looking for "bargains" in bakery is asking for trouble; choosing your bread according to your "social network" (who's composed of people who do not live right next to you) sounds completely useless.
It doesn't seem like bakers need to worry about Groupon, or Yelp. Is this just a poor example or am I missing something?
That's a little too good to be true, and the bakery example stroke me as very ill-suited.
I enjoyed the article, though, and I wish it were true that clueless incumbents would die rapidly and developers would get infinite leverage.
What I think is true is that developers will get a little more leverage while clueless incumbents will take forever to disappear.
(Edit: in the long run, everyone will be a developer. There will still be good and bad developers, but there won't be non-developers professionals, just like today there are not many people with a job who can't read or write.)
We are not all mechanics. In fact, the knowledge of how to make a simple repair like fixing a puncture in a tire is much less prevalent now than it was forty years ago. Nevermind the knowledge of how to troubleshoot a vehicle that won't start.
The consequence of this is that knowledge of the mechanics of the complex system that is a modern vehicle is typically beyond any one person, and certainly well beyond the majority of its users.
Today there is leverage in far flung industries for the individual who has specialized knowledge of his field AND knowledge of how to apply software development to that field. But these opportunities will not last long. Any software that can increase profits in an industry will attract competition from other software developers. That software will be improved and refined by software specialists. It will (and has) evolved to a systemic complexity that equals the modern vehicle.
Software is a tool. The civil engineer who uses AutoCAD to design your road does not need to know how to code his own AutoCAD.
Although industry standard tools with scripting environments often have active communities of people developing sophisticated tools on top of them. Encase is one example; the Canadian Mounties write quite a bit. Splunk is another. Niches may asymptotically outrun good software.
If you have to drive 30 miles to find a bakery then it makes sense to try to find out which one is worth the effort.
Which makes me wonder: is this an American problem? In cities where
1. almost anything is accessible by foot
2. driving is extremely annoying and expensive
you have an enormous incentive to choose services based on proximity rather than their current Yelp rating (or lack thereof).
It is a combination of hipster fantasies, delusions, and a hope for a business model.
Yet, I've never eaten anything from it, preferring several alternatives that are several blocks away. Why? My coworkers warned me of dubious sanitary practices (it even looks dirty), and none of them eats there. So "social" made me not choose that bakery.
A new worker at my building might not know of that, and thus might ignorantly go to that bakery. More likely, a contractor, deliveryman or similar, would find such a service very useful.
You're missing the leverage that software gives you. A bakery that keeps track of its Yelp reputation and works hard to maintain a 5-star rating will attract customers from all over the city. It might even start attracting out-of-towners who are in for a visit. This bakery's "market" is effectively unlimited because in any major city, there are going to be out-of-towners flowing in and out on a regular basis, and some of them will be looking for a bakery.
A bakery that doesn't do as well at maintaining a good reputation on Yelp will have its market limited to reach of its advertising and the word-of-mouth of its customers. Now, in a relatively tech-heavy town like San Francisco, that might be fine. If you provide good croissants, you'll get mentions on blogs and Twitter, which would magnify the word of mouth effect in a manner similar to Yelp. But if your customers aren't bloggers or heavy users of social networks? You could have the best bread in the world and not be rewarded commensurately, simply because not enough people know that you have the best bread in the world.
Never used Yelp, but do you really need a developer to do that? Would think the easiest way to get a good rating would be to hire some people to write good reviews for you and trash the competition.
(OT, but I bet sites like that will get less and less useful as more companies start gaming them)
However, it's inevitable (or at least hugely likely) that you will be found out and your repution ruined. Competitors will likely sue.
It's probably cheaper and easier to hire a developer who can write tools to monitor reviews posted online, manage a website, run your facebook group/app, write an app to make it easy for customers to order bread from their mobiles, and so on.
All of those things are legitimate activities and add genuine value to your business. They are also things that are impossible to achieve if you don't have technical knowledge.
> > Hiring people to "write good reviews for you and trash the
> > competition" is a quick way to establish a very short-lived
> > repuation boost.
>
> However, it's inevitable (or at least hugely likely) that you will
> be found out and your repution ruined.
I'd really, sincerely like to know -- as I can't tell which strongly positive or negative reviews on various sites like Amazon, IMDB, etc, are written by hired reviewers and which are real.
Of course, I have my suspicions.. but no real proof. And I don't see any way to ever get real proof -- unless the reviewer confesses.
So.. what's the secret?
Secondly, a sudden increase in the number of positive reviews should be fairly easy to spot by a competitor who has already hired a developer to watch for such things and do automated sentiment analysis on the reviews of competitors.
Thirdly, it's entirely possible that a broader-spectrum monitoring of reviews (perhaps provided by a third-party service) could identify common authors and/or text that is likely to be fake by analysing the content of the reviews themselves. This would help pick up paid reviews that were placed over a long period of time.
Why would they go public? They're presumably making (what they consider to be) good money writing fake reviews. By going public they'd be 1 - losing their revenue from you, 2 - undermining the public's confidence in reviews, which would translate in to a less lucrative business for the provider of fake reviews.
As for blackmail, I'm sure it happens from time to time. But I don't know how to estimate the frequency with which fake reviewers blackmail their clients. What is your basis for estimating the probability of such blackmail as "very likely"?
Furthermore, blackmail is an obvious risk for any secret/illegal undertaking, and yet people attempt try to do things in secret and break the law all the time. Clearly, for them the risk seems worth it (at the time).
"Secondly, a sudden increase in the number of positive reviews should be fairly easy to spot by a competitor who has already hired a developer to watch for such things and do automated sentiment analysis on the reviews of competitors."
So, the fake positive reviews might be staggered over a reasonable period of time. But even the business receives many positive reviews in a short period of time, that's not proof the reviews were fake.
"Thirdly, it's entirely possible that a broader-spectrum monitoring of reviews (perhaps provided by a third-party service) could identify common authors and/or text that is likely to be fake by analyzing the content of the reviews themselves. This would help pick up paid reviews that were placed over a long period of time."
Are there any such services which claim to be able to detect fake reviews? Or is this mere speculation on your part? Regardless, just because some service or algorithm claims a review is fake doesn't mean it is. Once again, their guess/estimate is not proof.
Sorry, my bracketed "(ex-)employees" wasn't really clear enough. I was trying to suggest a vengeful motive after they had been fired.
> What is your basis for estimating the probability of such blackmail as "very likely"?
Basic human nature. If you're directly employing people whose job is clearly unethical then you're painting yourself into a corner. Either they do in fact actively blackmail you or else you will feel unable to fire them in case they start telling people what you're up to - I'm regarding this implicit threat as passive blackmail here.
I agree with you that there are lots of people who seem perfectly happy to do unethical or illegal things in order to make a living. They calculate (if not always very accurately) that the potential gains outweigh the potential costs.
However, a lot of these people make such a decision in light of particular circumstances e.g. their low intelligence, or their lack of employability (due in part perhaps to an existing criminal record), or their unwillingness to work.
Someone who has established a business that is making enough money to pay the bills should clearly be reaching a different conclusion to these sorts of people (at least most of the time). Their potential losses are much higher (i.e. loss of the business) and the potential gains are actually not all that favourable compared to doing things the "right way" - for example, by hiring a developer who can boost your business in other ways.
> But even the business receives many positive reviews in a short period of time, that's not proof the reviews were fake.
It's evidence. What a business owner might do if they suspected a competitor had hired someone to "opinion spam" is up to them. If they though a competitor was paying someone to post negative reviews of their own business then they could very well sue, and request access logs etc. from the review site in order to further the investigation.
> Are there any such services which claim to be able to detect fake reviews?
I haven't looked. But it would certainly be possible to create such a service without too much difficulty.
There are "bad breads", or even "mediocre breads", but beyond that, all breads are interesting, each in its own way. I'm not sure I would want to eat the same bread everyday just because it's the "best" one (according to a bunch of Yelp users).
I don't think this "winner takes all" analysis really works for food.
Let's think about something else outside of food. There is probably such a thing as "the world's best laundry service", but do I care? I won't drive ten miles (or even 1 mile) to find a better laundry service, be it marginally better or even incredibly better, if the one that's nearest me is affordable and good enough. I will never know they exist because I won't look for them.
So I'm not sure "winner takes all" works for proximity services in general.
That's not to say that technology cannot disrupt those markets; someone could build a machine that lets people cook incredible bread in the house (it's been tried, and failed miserably up to now, but that doesn't mean it can't happen).
But the whole "bakers need to become experts at managing their online social reputation" line of reasoning strikes me as misguided and, frankly, the root of a lot of evil in modern society.
I'd rather patronize bakers who are experts at baking. There are many of them.
A lot depends upon the focus and goals of the business owner. The owner that is happy staying as a corner boulangerie could get just as much accomplished by making sure that they are active on a neighborhood mailing list that distributes a hardcopy newsletter to each new resident arriving in the neighborhood, than by paying someone to manage their Yelp presence, for much cheaper. Somone who wants to run a local chain of coffeeshops that push their baked goods on the other hand, might find it more feasible to pay someone to manage their Yelp presence.
The author doesn't make this clear, but I suspect (due to the Forbes origination of the content) he assumes the reader is someone who intends to run a scaled-up business as opposed to a classical "small Mom & Pop" operation. Otherwise, I find the "software as core" argument he puts forward a little difficult to buy into.
(which does have excellent coffee, by the way...)
As usual, there are a few startups working on that :) (I know of one).
I still like the "trying out new stuff" approach, but I can see that experience being augumented by social networks.
He elaborates on the "guild-like mindset":
> The other kind of developer turns to guild-like structures, which serve as centers of balance-of-power politics in the constant wars against the developer-capitalists. Except that instead of taking on the dynamics of class warfare along an upper-lower dimension, the conflict takes the form of exit warfare along an inside-outside dimension. Rather than form a union to negotiate with management, the talented developer will simply exit a situation he/she does not like, and use guild-like resources to move to a better situation. Stock options are simply not as effective in limiting mobility as the power of Russian nobility to whip serfs into immobility once was.
I've tried to make sense of what that means, but I'm lost in the balance-of-power, upper-lower/inside-outside, and guild references. If someone has a moment, could they please explain this paragraph in clearer terms? Perhaps as a basic narrative of what a guild-minded developer would do when she recognizes her value?
http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...
This is a style of writing that should be valued more for the questions it raises than for the ones it answers. As another example, take Marshall McLuhan; much if not most of what McLuhan says in e.g. Understanding Media is somewhere between flimflam and complete bullshit... but the mode of thought starts the wheels turning, and some otherwise solid seeming cultural assumptions are questioned at their core... and at the end I’m really glad I spent the time reading it.
Witness, for instance, the rise and fall (and rise again?) of "The Long Tail." As a concept, the long tail certainly applies to some businesses. But not to all, and not nearly as successfully as the concept's author once claimed. But the business world was frenzied with long-tail fever for years on end. "Long tail" became the buzz-phrase of the day, even in companies for whom the concept made no sense whatsoever. People with no understanding of the underlying principles could, nevertheless, grasp the surface-layer metaphor -- and, in so doing, assume that they understood the whole thing. That's a dangerous mindset.
So there's a sort of Faustian bargain in all of this. Appending a nice metaphor on top of a concept increases the likelihood that the concept will be disseminated, talked about, and taken up. But, at the same time, it invites intellectual laziness and fads of half-baked thought.
As you say, the problem is just grasping the surface metaphor without examining the details. For myself, I like having the surface metaphors as a way of storing and communicating ideas, because once I’ve established that someone has a deep understanding of a concept, I can talk about it at a high level with a high data transmission rate.
http://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty
For developers, it is swinging back towards exit, since the Internet can be considered a kind of virtual equivalent of the nomad regions to retreat to.
"Center-periphery" dynamics is the common term in geopolitics for dissent dynamics driven by movement inside/outside a core. Class warfare is the better known kind of dissent involving unionization etc. and involves fighting up and down a class structure.
Guilds, historically, were a medieval kind of institution that had characteristics of both exit and voice. The classic guild professions (weaving, masonry and in more recent times, things like typesetting in pre-lithography days) used their portable skills to leave kingdoms/cities and move elsewhere if they didn't like their current situation. This option was not really available to laborers tied to the land, and was essentially an urban phenomenon. This is the origin of the term "journeyman" for instance... apprentices who would follow master craftsmen around until they became masters in their own right.
Is there some way I can contact you?
No, that's not right. When an apprentice finished their apprenticeship, they would usually have to leave their master's service. The openings for masters would be fixed per town by the guild, so journeymen would work itinerantly until they found an opening to become a master. Journeymen would work for a series of masters, and their relationship to these masters was entirely different to the relationship of apprentices.
The status of journeyman became institutionalised, so that the criterion for taking up a mastership was that one had travelled widely enough as a journeyman for some length of time and had crafted a masterpiece.
I've never heard of the idea of guilds organising flights: I should think that master guildsmen had more to lose than agricultural laborers from relocation. Perhaps if several guilds coordinated, it could be less than massively destructive. Where did you get this idea?
Yes, the guild system and town laws often made the journeyman itinerant, but it wasn't travel that put the "journey" in "journeyman".
Epstein has an article on craft guilds in the Oxford Encyclopedia of Economic History: http://www.oup.com/us/pdf/economic.history/craft.pdf
When a developer find herself working in a company that undervalues her, she will typically react one of two ways:
1. "Individualistically": Such developers might begin by bargaining for better terms at their company, but they are quick to leave the company to 1) consult, 2) join/found a startup, or (following way in the distance) 3) join another company. Individualistic developers invest time in learning new technologies to stay current, because their ability to be so mobile exists primarily because they can work in such varied environments. These developers still seek large windfalls, so they "hedge their bets" - taking high-risk jobs more often than most people. Individualistic developers are probably younger than other kinds of developers.
2. "Guild-Minded-ly": Such developers will respond to workplace injustice by leveraging their connections to find another job - probably at a company with similar specifications to the one they are leaving. A guild-minded developer might be an ex-Google employee who - over the years - has built relationships with people at Microsoft and Facebook. In order of preference, such developers seek jobs with 1) another company, 2) a startup, 3) themselves (consulting). Stock options are less effective at retaining guild-minded talent, because they are not as concerned with large windfalls. Guild-minded developers are probably older than individualistic developers, and they also probably want to stay at a job for longer.
The above is probably not a 100% accurate representation of what the author was trying to say. But if it is, I don't much care for it.
While it's true that some of us are more likely to work for ourselves, or tend to be risk-averse, or desire long-term relationships with a company, I don't think the author's division of mindsets encapsulates these motivations.
There also seems to be a lot of overlap between his divisions: Both sets of developers are active in the community (individualistic developers via open-source, and guild-minded developers via whatever a guild is - and probably via open-source, too); both developers are very mobile despite attempts to retain them; and both groups supposedly represent highly talented ("10X") developers as opposed to average ("1X") developers.
I found the article interesting - though I'll need time to digest it and form an opinion. But his decision to close with an articulation of this division is strange. It seems tangential to the larger point, which is that good developers (of whatever group) are important.
>>While it's true that some of us are more likely to work for ourselves, or tend to be risk-averse, or desire long-term relationships with a company [...]
Basically, developers with more of a mercenary mindset are more willing to work for themselves, while developers with a more guild-like disposition tend to be more risk-averse and/or desire long(er) term relationships with a company.
Both groups definitely overlap in terms of their achievements and community involvement. But how they see themselves in the market, and more importantly how they react to changing conditions, seems to be the primary distinction between the two.
Being a Forbes article and the general audience that the author seems to be writing for, I doubt that much of this is anything new for a HN audience. However, it's probably a good radar ping/wake-up call for the more general audience.
tl;dr Polarizing divisions make it easier for people to retain information.
But there was also an element of guild behaviour in that anyone who found themselves in a good project/company tended to bring in others.
Sigh. ::Closes eclipse. Googles "ruby tutorials"::
On the other hand, this is simply the flip side of the frequently-heard argument around here that technology is driving people who can't cope out of the ability to hold a job at all, because they become unable to produce value in excess of what they cost. If that is true, then it follows that as the supply of people who can still be productive in the new economy drops, then they must also go up in price.
The article paints a simplistic picture, which is probably not correct even to first order, but it may be a useful viewpoint. The stratification should only increase, with the super devs obsoleting the ordinary code monkeys, but the time frame on that might be large.
The robot owners get value in that they can lower their prices because of the replacement of labour with robots, and overall, society benefits because whatever the robots are making is now less costly (ie, takes less of your own hours working to purchase).
The key to understanding all of this is productivity. Most people tend to think in terms of raw job numbers, rather than productivity numbers.
Employing robots results in a more productive economy because the same (or greater) amount of output is achieved with less human input. This does release labour from that activity, but it also creates opportunities in other areas, as the savings people make on purchasing the robot-cheaper goods can now spend in other areas, which should create jobs in other areas.
Of course rapidly advancing technology produces lumps of unemployed which take time to retrain and redeploy themselves elsewhere, and it sucks to be that person. But eventually they will find employment, assuming something else isn't working against that (like oversized debt accumulation, which works against new enterprise creation by causing a negative investment flow, but that's another story)
After thinking about it there is an interesting notion in there. If you consider how the author may benefit from writing such a piece (as opposed to any other piece which would have resulted in him receiving the same payment).
If we assume that hypothetically he is simply writing what developers like to hear, then it is likely that he is trying to curry favour with either a specific developer or developers in general. If he was trying to do that then it implies he sincerely believes what he wrote and therefore wasn't just writing what people might want to hear.
Admittedly it does fall apart if it transpires if his motives were 100% financial, however I found the concept of a self-negating idea to be an interesting one.
That said, I found the point about being a capitalist or a commodity relevant to the startup scene in many important ways. There are a lot of people who want me to be very smart with code and very stupid with money.
First, he is telling developers that they are awesome. That's nice to hear, and of course will guarantee a friendly reception by developers. :-)
Secondly, he is arguing that all businesses will be heavily software driven, and if they don't invest in IT, they will be winding up buying from a "cloud" provider.
Thirdly, he is arguing that management needs to take a long position on hiring(non-pedantic note: a long position is where you expect a stock to go up, it is the "buy low sell high" approach), because it will pay off massively. Investing into software creators on the 50-year plan will provide heavy returns, because business are becoming software-ized, and it will pay off.
I think in the scope of the next fifty years, the author is correct in that software will be one of the core strata of societies across the board (I don't see us there yet by a long shot - some places don't even have electricity still).
http://www.salon.com/2011/10/13/the_tribesman_who_facebook_f...
But, you know, I would argue that someone in that region needs electricity to hook up the facebook. :-)
Full agreement on this point. Once I started looking at my own career from this perspective I couldn't stop. Books like The Passionate Programmer and The Pragmatic Programmer as well as heaps of prose from pg, patio11, edw519, and tptacek guide my continuing quest for increased leverage.
I have a hard time understanding this: programming skills are extremely transferable and learning the hot language/platform of the month isn't extremely difficult. Is it just inertia that prevents them from doing this?
Those who are good at it just don't get how hard it can be for those are not quick learners in this sense. This is part of not knowing their own value -- claiming that learning new languages is "easy." It is. For them.
I think one of the things that's hard for people is that thinking along a particular type of technology for people creates a type of mental rut that means subsequent thinking tends to go down the same rut.
By this, I don't mean it so much as the 'stuck in a rut' sense of being unable to escape, but more of the fact that it's hard to approach a problem without using an existing mental pathway you've spent years using.
It's like trying to learn a new (spoken) language - you tend to try and think in your old language and do the conversion, rather than think in the new language. The people who can pick up new languages quickly apparnetly have a good ability to skip over these mental ruts and embrace new types of thinking quickly.
So people struggle initially to understand new technologies because it might require a different type of thinking. And they may also have no chance to practice these skills without leaving their existing job, which might involve a significant cut in income and/or a relocation.
Of course the end-run around this is to be involved in an open source project in the new technology, and try and pick up work through those avenues.
The other issue is that, as a technology gets mature, as long as it is still being used, the dollar rewards tend to go upwards as time goes by. I personally know of guys who still work on database systems written in the 1980s which predate relational databases. They are the only ones who know it, and are pretty much untouchable for both domain and technical knowledge. They get to work from home for large money and are off-limits as far as cutbacks and layoffs. Of course, this all happens up to the point a new system is put in place, but, as the article says, old systems are geographical layers, so businesses can tend to build on top of the old layer and glue it together with middleware, rather than do a bottom-up rebuild.
So if you're making big money doing something you can do with your eyes closed, and are indispensable, there's not a lot of incentive (beyond intellectual curiosity) to switch out into a new stream. The people I know are financially set anyway, and they just see it as a revenue stream that will one day dry up, but are happy to keep taking it while it comes in.
I've already mastered an x-number of technologies in my 25 years as a developer, I'm 100% certain I can deal with the umpteenth new one (albeit a bit slower than I used to). I already know I can program, and what my strengths and weaknesses are in that area. I'm more motivated to take on challenges I might actually fail at, or learn something new about myself.
"If we really want to become smarter, we will have to resort to the hard work of building more effective representations within the existing processing capabilities of our brain. Modern neuroscience backs me up here (e.g. summary in nice NPR interview); the process of compiling our experience into higher and higher order patterns that we use to structure future experience is what makes the judgement of experts more efficient than that of a novice (not always more effective, as the higher order patterns can also limit our generative abilities)."
You can be a very effective developer (at least in certain contexts) without building robust mental representations which allow you to assimilate newer techniques easily. And there can be cases where this is an advantage.
So more concretely, people recommend learning tools like Lisp, to give your mind mind practice with a more abstract, meta way of working. (So you can explore and rejigger new ideas without necessarily writing a classical compiler and idiosyncratic language from scratch.)
I don't think it's just inertia, at least not in my case. I know that my example it's just anecdotical, but I'll write it down anyway.
I'm in my early '30s, I've been programming in Python for 7 years now (and during the last 6 years I even got paid for the privilege), along with other languages (PHP, JS etc.)
The thing is there's only so much that you can learn about the world around you by focusing on only learning programming- or tech-related subjects. Of course that, for example, learning Erlang or Caml are extremely interesting things to do, intellectually speaking, but when I realized that by learning to speak Arabic of Farsi I could potentially be able to interact with and to better understand the culture of tens if not hundreds of millions of people then my interests slightly changed.
Of course that it wouldn't help me one bit if I were to tell my potential future interviewer "hey, I learned to speak Farsi so now I can really read Hafiz's poetry the way it's supposed to be read", but as long as that experience enhances my understanding of the world around me it's all for the best.
Re-reading what I wrote I realize maybe it doesn't make much sense, anyway, what I wanted to say it's that most of us, programmers, are (really) smart people, it comes a point in one's life when you realize that there are other things in life worth spending your time on.
I think though, that for the general audience it is intended for, it might wake a few people up to the fact that software is a core competency for just about every business and not a cost centre, and that competitors who can use software well are well positioned to outstrip those who can't.
Further to that point is that, to get good software, you need good developers. And if you aren't actively trying to work out how to get the best developers, you're getting the leftovers.
This fits neatly into the point I was making recently about government projects always being doomed because they end up with bad developers on projects with too many owners, and that governments everywhere should just buy off-the-shelf solutions and fit their way of working to them, rather than the other way around.
Initially I had a strong reaction against what you're saying here, but I see you chose your words carefully, saying gov projects "end up with bad developers on projects with too many owners". Sadly I have to agree, since I am in that world in the federal gov and see it first hand. But there are many highly talented developers here! They typically don't stay on projects long enough, so "end up with..." is exactly right.
And that does tie in to your point that "to get good software, you need good developers", so it's a never-ending challenge trying to find and keep those 10xers engaged and happy with their work so they tend to produce that 'good software'...
Many times the requirements of an agency/office/mission are too specific for something off the shelf. The solution has to be either completely custom or a mix of COTS/GOTS. And when you have a mix you have integration. Software is a smaaaaalll part of the equation in government. It's the solution engineering (read: consultants/contractors) that cost the most. And I bet you'll always need/want highly skilled engineers for all sorts of roles. innovation is one, but keeping missing critical systems alive and operational is important too. what qualifies as 'mission critical' is another subject for another day, and can vary wildly depending on who you talk to...
However, a lot of times, the requirements are truly simple, or simply met. And I think that's why you see a TON of Drupal being used in the gov these days. For many offices, that's all they ever needed. But even that's a smaaaaaal part of the pie. The government is huge! You can't imagine how many thousands of software projects are all going on at the same time right now...
The vast majority of government IT systems are very ordinary things that are used all over the place.
Things like: payroll, issue tracking, asset tracking, emergency services management, waste disposal, vehicle registration, fines management and payment - the list goes on and on and on.
Yet time after time we find a government department insisting that their payroll system is unique because of x, y and z, and that their asset tracking system requires a custom solution.
This should be flipped on it's head and instead it should be : here are the top 3 whatever purpose systems available in the market. We will choose which one suits our needs the best, then we will change our work practices to best match the system.
Because changing the work practices will be easier and more successful than trying to build out (or customise) their own IT project.
But this requires people to think about practical solution, and to no have IT empire builders.
No government tries to re-invent railways, roads or sewage to their own needs- they look at what works elsewhere, and adapt to the technology available. Yet they go in the opposite direction when it comes to building computer systems. When you look at the graveyard of wasted billions on customised government computer systems - it's time for a new approach.
Most of those on the list are things that the gov already buys off the shell software for (I have worked as a network administrator at a large state university in the past). Our payroll system was off the shelf from Oracle, asset tracking was part of that erp system, our course management system was the off the shelf blackboard, security access system was from another vendor. It was rare that a project would be 100% built in house.
Using payroll as an example, for the size of these organization, the off the shelf components you will find are usually built with the expectation that it will be customized anyway. (Not all organization in government work the same way for very good reason. Laws) They are incomplete in a lot of cases and require integration with various system. The above poster was right, the problem is often integration. How to I plug my directory services into my erp system that connects to system for another agency somewhere. You will have a hard time getting a unified system across all agencies when you go by a biding system that is anywhere close to fair.
The companies that play in that space Oracle/SAP/HP/Novell whatever are all built on the assumption that you will buy something and need their help with it for years to come.
The problem is huge I feel you are underestimating it.
1) "If your bakery doesn’t have an iPhone, it will soon be at the mercy of outfits like Yelp." - What does that even mean?
2) "A little known fact about Google, for instance, is that its investment in Python (one of the three languages the company uses for its work)" - Gonna go out on a limb here and state that Google uses more than three languages.
The second quote is pretty easy to support with sources. Google has three _official_ languages that can be deployed into production, and Python is one of them. See [this post from a Googler](http://everythingsysadmin.com/2011/01/python-is-better-than-...), for instance. I have no idea how hard a rule this is, but many a Googler has mentioned it. I think it's worthy of being called a 'fact', and thus completely valid in the article in question.
For 2. I'd say he's right in that python has played a fairly large role in Google's developer outreach and seems to be the lingua franca for expressing ideas in code within Google.
The first point is just sloppy, and suggests that Forbes doesn't engage in the outdated and unfashionable practice of editing it's writers. The second is a fairly pedestrian observation about the software industry, that languages and technologies are identified with some entities more than others. That the languages a person who is a developer knows may affect his view of companies that use them is not in question, whether it's a benefit to the companies in question is unknowable.
There are likely uses of other languages internally for small projects or one-off kind of things, but large companies generally prefer some standard practices/patterns/languages. For well written code, you have to realize, your code will likely outlast your employment. That means someone must maintain it, fix bugs, augment its functionality, etc... It is MUCH easier to manage that whole flow with strict(ish) stylistic standards (Google has these) and a small range of possible languages. If you've ever seen code written 15 years ago in the (then) language du jour, with no sort of consistent/recognizable style/coding patterns, etc.. you will understand why companies do this kind of thing.
This model may not be for everyone but it allows us to bring in great non-staff writers like Timothy Lee (http://blogs.forbes.com/timothylee/).
While contributors can still pitch mag stories there's still a lot of editorial involvement in the print publication.
For a long time the 3 "approved" languages for use in production systems at Google were Java, Python and (a subset of) C++ (Javascript was a fourth language, but was a special case - used only in the browser) [1][2].
I believe that has changed recently with Sawzel, Go, Dart, etc, but he is correct in principle.
[1] http://panela.blog-city.com/python_at_google_greg_stein__sdf...
[2] http://dave-ford.blogspot.com/2008/01/googles-4-approved-pro...
Anyway, I don't think this article is going to help the author find the "technical cofounder" he's looking for. The fact that he even uses that term pretty much guarantees that he's not going to find a 10xer, even if that mythical creature existed.
I for one can't wait for the social bubble to burst so programmers can flow back into the currently neglected branches of software development - we're getting old and lonely and could use some fresh talent.
It is the same mindset of the founder "just looking for someone to build it". The though of learning it themselves, literally never crosses their mind because, they are not of that personality type.
It's akin to saying people that go into finance where worth their weight in gold in the 90's, why didn't you go into finance, may of us did in a way, but most of us used a wealth manager, broker, mutual fund to do so. Developers are like that wealth manager, they do all the technical work that investors do not want to do. Some people take the time to learn the models and self direct their investments, but they are the minority.
Most use a professional, though I doubt many investment professionals had to deal with the: "hey I have an idea I want you to build, I have no money, but I will cut you in for 10% propositions".
Think about what software can do for a bakery:
- use the web to sell more product
- save gas money and time when delivering to wholesale customers
- make production more efficient
- use just-in-time ingredient ordering to keep spoilage and inventory costs down
Perhaps you build those systems in-house and they (in addition to a killer baguette) are what makes you special.
Or perhaps you productize your software and make millions selling it to bakeries (or spin off a company to do so).
How will the baker who knows how to make good bread but doesn't know how to leverage software compete with you?
I understood his argument to be that software developers are becoming increasingly valuable, and outsized returns will go to firms that understand this and learn how to treat software developers well to leverage what they're able to do to any industry.
Here is a quote from the article where he lays out the Andreessen Hypothesis[1], and links to David Kirpatrick's article that restates that hypothesis into a format more readily grasped by business readers[2].
Which brings us to David Kirpatrick’s now famous line that every company is now a software company.
We are only just beginning to understand how software is now the core function of every company, no matter what it makes or what service it actually provides.
I have some reservations about these kinds of sweeping proclamations (which if I posted would turn into a tl;dr for most people), as they miss a lot of the nuance of the situation on the ground. That might be deliberate, as part of consulting at these guys' level is to get clients hooked on the sizzle of a catchy idea, then sell them the steak of the nuances you've worked out.
[1] http://online.wsj.com/article/SB1000142405311190348090457651... Not that Andreessen was the first to realize this of course, but he just happened to catch the news cycle with his verbalization of this observation at the right time to break into a more mainstream meme, that many in the industry already either tacitly or explicitly acknowledge.
[2] http://www.forbes.com/sites/techonomy/2011/11/30/now-every-c...
I think you're still in the publishing / music / insert_industry business; software becomes a core function of your business.
But I don't think your core business necessarily becomes software (though it could).
What if the bakery was built around an automated production system driven by software that lets a master baker key in the latest recipe tweaks to a baked good product that works great in a small batch, and automatically works out the changes necessary to scale it up (or maybe it is so automated that it can mass produce in small batches), sets up A/B testing in limited distribution areas, and measures the results...the very same day that the tweaks are made? Or it can permute variables in the first production run, yielding a few dozen samples laid out in an array, let the master baker (or apprentices) taste test, tell the system what result to modify, and dynamically adjust, permuting in a day of testing what would take a conventional bakery a week or more to work out what to do in production?
What if the automated system is so modular and flexible that it can do whatever a human baker can do, simply by watching a baker perform a single rendition (with appropriately-instrumented tools to sense pressure, flow, orientation, etc.)? What kind of competitive advantage would it confer (if any) to allow a bakery to start mass producing baked goods on demand for special promotions and occassions, in the time it takes a conventional bakery to produce a single prototype?
What if the marketing department has software that enables them to set up A/B testing for a different package artwork, and tweak it day-by-day, comparing against historical sales data and adjusting for economic conditions?
What if the sales department has software that can deduce the relative stock levels of competitors from the phone cam video taken by delivery and stocking employees of the bakery that stock at grocery retailers, and pounce to deliver more stock when the competitors are running low on stock but won't know until a couple days from now on their regularly scheduled stock deliveries?
These what-if's do not really apply to the baker that only wants a small corner bakery in the European style, serving only the neighborhood within a walkable distance, and taking a craftsman's approach to their pursuit of their art and livelihood. For that context, I believe you are right: the core business is all that really matters, and software is merely a tool for reducing frictional costs of doing business. I suspect Andreessen, Kirkpatrick, and Rao are thinking of mid-size and larger-scaled businesses when they discuss this observation/trend.
The huge assumption here is that the flexible fabric of software bytes is translated across into some directable and malleable bits in the real world. That happens, but it many times doesn't come cheap. I wonder if the proponents of this trend are vastly underestimating those costs.
Those who manage, tend to blog more because they have less to do in front of a computer.
Kind of a useless and filled with false assumptions.
I suspect after the bubble pops we'll be reading 'the talent myth'-type articles in Forbes.
Honestly, I think there are some interesting ideas there but I am not sure if those ideas are the author's or just a random collection of memes he picked up from the Internet.
I started programming when I was six years old. BASIC on the TRS-80 Model 1. I aggressively studied programming because I thought computer games were cool, not because job prospects were hot.
If a recruiter today tried to tell me that I had to stick to BASIC on TRS-80 because I started out there, I'd think he was nuts. Many recruiters actually believe this ludicrous idea and ARE nuts. It's not "re-inventing yourself" to learn a new programming language mid-career or at any time. Good hackers know it's simply learning another way to apply your skills to a new set of challenges.
Are there any studies showing how the potential to learn programming decreases (or not) with age? I have looked on Google Scholar but I found nothing.
>> thinking of people of 35-50 years old ...
http://norvig.com/21-days.html (Teach Yourself Programming in Ten Years)
So true, so true. We have already seen a spate of that this Fall, unfortunately.
Stopped reading one paragraph into that section.
>>You need to find a way to invest in software developers.
Sigh, the gold rush will start again...