Yes, it's true. At the end of the month, my journey with Magenic ends.
It has been a great ride. This time with this company - has been, so far, the highlight of my career, bar none. The people - especially the technical people - are incredible.
To put it another way, there are probably 5 companies in the world I could ever work for. Magenic, Google, Microsoft, ThoughtWorks, and my own. Magenic is certainly one of them. But I am moving from one of them to another - with all the enthusiasm, mixed with "oh @#$# what did I do!" you could ever imagine. The hard part about leaving a company like this is that it is really like leaving your family. Nobody wants to really do that. And few that I have ever known really felt "fantastic" about leaving Magenic. And I am certainly not one of those few.
All good things come to an end, however, and the time for me to move on is here. If you are interested in continuing the story, you can follow me at twitter.com/aaronerickson - or at my book blog at nomadic-developer.com. Heck, I may even open up a new technical blog at some point in the near future :)
I leave you with an excerpt from my book - the "Survival" chapter - which I found very easy to write in October 2008 when it seemed the financial world was closing in on us. It is timely now... though I am hopeful that in coming years, consultants will not need such a chapter in a book dedicated to their careers.
I also leave you with this video. I know it is a little corny. Whatever - I like it - it helps me put things in perspective. There are all sorts of things in life we can worry about. But when you get down to it, the key message I take away is that what will happen - that is - the risks you think will manifest, are almost always wrong. It is the things we don't anticipate which really surprise us and mess us up.
The time has come for the official announcement that this blog is moving to nomadic-developer.com - in advance of my book coming out.
Please update your bookmarks. If you need further inspiration, I have a new post up that talks about the biggest career risk you can ever take! (enjoy)
Cross post from my Nomadic Developer blog.
Note - the book... that one about the technology consulting business I am always talking about, is shipping in less than two weeks - by all means, pick up your copy here.
The first of my initial 5 articles on technology consulting careers is up on InformIT - installment one is 10 Questions to Ask Before Joining a Technology Consulting Firm
The article touches on broader themes I touch on in my book, The Nomadic Developer - being printed now and to be released at TechEd.
As I say in the article - companies are hiring, but the process is far longer, travel is likely to be required, and flexibility is a watchword in this less than ideal market. But despite those issues, work is still getting done, deals are still getting signed. It is not quite the nuclear winter in tech right now that it was in late 2002 and early 2003.
Yes, its true, I am returning to VSLive Las Vegas in June to do a couple more talks, this time on:
* Indexed LINQ - use indexing to make your Linq queries scream...
* "Writing Code that Writes Code" (a talk that debuted at Twin Cities Code Camp 6 last weekend) - who said the LISPers should have all the fun...
As an bonus, use the code S9V08 to receive a $400 discount from the conference fee. Jason Bock and Rocky Lhotka will be there as well.
Looking forward to seeing some old and new friends there :)
After reading Ayende's latest post about M, M is to DSL as Drag & Drop is to programming, I was starting to wonder if doing a binding DSL was worth the trouble.
I suppose I should probably state what a binding DSL is:
"A binding DSL is a domain specific language for the specific purpose of binding objects - notably ViewModels, to a screen that represents a rendering of that ViewModel"
In an ideal world, instead of setting attributes for binding all over your xaml file, you would have a nice textual binding file, written in the binding DSL, that states what things link to what elements, such as:
CustomerGrid binds to _customerCollection using _customerTypeId in both directions //specifies that the grid binds in both directions to an object
CustomerTypeDropDown binds to _customerTypes with TypeName as Text and TypeId as Id //typical one way binding
//... and so forth
My acid test for whether M and Oslo are useful is if, in Oslo, I can basically do the above, without having to deal with a ton of pain. That would mean:
* DSLs can be translated, using various Oslo tools, into the language of choice (most demos I have seen turn them into SQL... can I have C# please?)
* I don't have to depend on the repository - please don't make me use SQL Server in my build process. I beg you.
* I have a nice model for managing DSLs in my build environment. A DSL does something when you turn it into something else - I want control over what that process is.
On this last point, I have direct experience. Several years ago, I was the architect of an application that, in effect, interpreted a significant subset of SQL. My colleagues and I wrote a "good enough" SQL parser as a LEX grammar. In order to build, we had cygwin running on the build server, which would run the grammar through LEX, produce an application that would generate a token stream, but then skip the YACC step, and rather, interpret the token stream on the fly to run our queries against a custom hashtable based data model. It was convoluted, but it worked. If I was able to do that 6 years ago with simple command line tools, I ought to be able to do that with Oslo, MGrammar, etc.
Put another, simpler way, I hope Oslo turns out to be a language tool, like LEX and YACC with a nice GUI on top, and not some tool that requires a mouse to do anything useful. The latter would really be a bummer.
A note to readers - if you are in the Seattle area, let me know. I will be working from Seattle during the week for an indeterminate amount of time, likely at least seven weeks - probably through October. No, it isn't Microsoft (to disarm everyone's first question upon learning the news).
Now that my book is largely done, I finally have time to focus on some things that have not received the attention they deserve lately. Thankfully, Jason Jarett was kind enough to introduce some great new ideas to i4o, which after having mulled over them for far too long, I am releasing into the wild as of this weekend.
Details of the changes are nicely documented on his blog.
The jist of the changes though are to introduce a better way, leveraging lambdas, to specify an index (the new IIndexSpecification<T> interface). Prior to this release, you either had to use attributes - something you can only really do with code you control, or you had to use strings to specify the property. IIndexSpecification<T> is a nice seperation of those concerns, so that your classes can truly be not concerned about how they are being indexed (as we have done with the POCO changes from the previous release), while more easily being refactored (i.e. member name change refactoring will now work with indexes).
In addition, performance improvements to reduce the number of lookups using reflection have been introduced as well.
I really owe a huge debt of gratitude to Jason, who took it upon himself to introduce these features and share them with the world. I am very excited about how this has evolved over the past year and a half.
As for where we go next, now that I am done with the book and have more time to work on open source projects, the next round of changes will (finally) widen the number of query types that can leverage the index, similar to the work Rocky and I did with indexing in CSLA. Look for that sometime in April/May of this year.
We will be continuing soon with regularly scheduled programming.
The last 3 weeks have featured nearly all of my spare time finishing my book, which is a typical cause of blog authors "going dark". Rest assured, there is a lot of stuff coming up in Feb.
Speaking of the book, the Amazon.com page for it is up - so by all means, preorder at will (please - make my publisher happy they too the chance on something so off the wall!)
On the docket for Feb:
* i4o update (new fluent interface)
* Binding DSL? (maybe if I have time)
* New Open Source Project? (more details when I can announce)
Stay tuned...
Every now and then, I will go to conferences and events where the topic of user experience will come up with a prospect. In said conversation, some form of the "what is the real business value of UX?" question comes up. While we often meet that by talking in vague terms about lowered training costs, I always found such conversations to not be terribly convincing. So lately, I have revamped my standard "pitch" (for lack of a better word) around UX, to something like:
[Prospect]: So, is there really any business value in making applications pretty? I am an important investor and I don’t want to waste money on fluffy crap.
[Me]: Do you fly on a private jet, or are you still flying commercial?
[Prospect]: Sadly, in this environment, we are flying commercial, so I settle for First Class.
[Me]: Whew – ok then, maybe you can relate then. Have you ever had to change a flight?
[Prospect]: Yeah, sure have. Once I was on this three city tour bla bla bla…
[Me]: Wow, well, don’t you wonder sometimes if that ticket agent behind the counter is really changing your ticket? Doesn’t it seem like she is doing enough typing back there to write an entire Masters Thesis?
[Prospect]: Sure does! There must be a lot of work to change from the 6AM to the 8AM flight to LaGuardia.
[Me]: Well, think about it. You can go online, or for that matter, to the Kiosk 6 feet away from the gate agent, and accomplish the same thing with 4 clicks and 2 keystrokes.
[Prospect]: Wow! You don’t say…
[Me]: In fact, think of all the money airlines could save if the UX on their systems that their agents have to use didn’t suck so much.
[Prospect]: No wonder airlines are constantly going bankrupt. Can I have your card?
The answer to "does UX really matter?" - heck yes. In fact, whenever I personally start to wonder when and if companies will start aggressivley investing in technology, I think about how much low hanging fruit there is in terms of UX for LOB applications, put a smile on my face, and go about my day, confident that yes, there is still quite a bit of work to do.
I have been beating this drum for some time now, but the
latest post from Don Syme confirms the trend.
Not only is VS 2010 going to include F# right in the box, but
the scenarios that it is being targeted for are, according to Don Syme:
“In this first supported release, our aim has to be to focus
on the core strengths of F# for exploratory programming with F# Interactive,
programming with data and implementing parallel and asynchronous
components.”
So, let’s put all three of those ideas together, exploratory
programming with data implemented using parallel and asynchronous
components. If I am someone thinking about BI, this should be
nothing short of nirvana in a box. When you add to this the
visualization components, and integration capabilities (i.e. easy to use
components developed in F# in any .NET environment) – the implications are
staggering.
It is becoming more and more evident to me that F# is the first step towards a real democratization
of BI – moving BI from purely being in the realm of “stuff you do on the
database” to being a proper discipline of its own, composed of good data, but
adding to it sophisticated models and functional libraries that help you figure stuff out.
Human intelligence is more than just the contents of memory
stored in your Hippocampus. The ability to store and memorize
facts – what we know as a database – is only a small part of the overall BI
picture. Obviously important, but by itself, doesn’t do much for
you. To really implement BI, you need to be able to imply things
from facts – to build rich models of interaction – a cerebral cortex that not
only acts as a digest of information, but is capable of integrating information
from various sources to tell you things that will not always be obvious to your
competitors.
To be fair, we have had languages on the database for awhile
for BI, such as SQL, MDX and so forth. The problem is that all
these languages exist on an island. MDX does not live anywhere
but in a database, tied to a specific database product.
Even SQL, the most general purpose of languages that people use with data, is
different on each data source, so much so that developers have been inventing
different technologies for an entire generation to deal with the
differences.
F# provides the first suite of tools available to nearly all
developers (not just the “Data Dudes”) on the Microsoft platform that will allow
them to do real BI work. What is exciting to me about F# is that we will have many more tools at our exposure to deal with data.
Here is one such case. In F#, we have an operator on the Sequence object called the pairwise operator. Basically, what pairwise does is take data that might be in the form of 1,2,3,4, and turn it into tuples of 1,2; 2,3; 3,4. Now, knowing this, lets say we want to do something useful, like write a script that reads web server logs to determine if a crawler is screen scraping your ecommerce site:
The pseudocode (okay, SQL from memory) to do this would look something like (and forgive me if I miss some syntax...)
--grab the 100 IP addresses that most frequently appear in the web server log
select top 100 count(*) from logentries group by IPAddress, pageRequested
--bind each row to @IP and @pageRequested, run this query on each returned row (max 100)
-- grab the IP addresses where, when the time
diffence between requests is a pattern of anything more regular than
"every 100 milliseconds".
select IPAddress as AddressToBlock from (select IPAddress, pairwise logtimestamp as (first, next) from logentries where IPAddress = @potentialCrawlerIP and PageRequested=@pageRequested order by logtimestamp) where (first-next) modulo 100 = 0
Now, while I am sure there are lots of mistakes in this (doing it from memory) - the biggest one is the keyword pairwise which does not exist in SQL. In F#, you use it, per the above, to generate a set of tuples that allow you to compare all previous and next pairs, something really useful in a lot of situations, particularly finding patterns in sequences of data, such as what you do when trying to find out a pattern from a web server log that relates to a crawler hitting your site.
The F# code might look something like this (including code for setting up dummy data):
#light
open System
type LogEntry = { TimeStamp:DateTime; Page:string; IP:string }
let someTestLogEntries = [|
//these are suspect IPs - regular pattern, same address
{TimeStamp=new DateTime(2000,1,1,0,0,0,3);Page="ProductPage";IP="127.0.0.1"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,103);Page="ProductPage";IP="127.0.0.1"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,203);Page="ProductPage";IP="127.0.0.1"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,303);Page="ProductPage";IP="127.0.0.1"};
//these come from different addresses, no big deal
{TimeStamp=new DateTime(2000,1,1,0,0,0,0);Page="ProductPage";IP="127.0.0.2"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,0);Page="ProductPage";IP="127.0.0.3"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,0);Page="ProductPage";IP="127.0.0.4"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,0);Page="ProductPage";IP="127.0.0.5"};
//these come from same address, but interval is more irregular, no big deal
{TimeStamp=new DateTime(2000,1,1,0,0,0,0);Page="ProductPage";IP="127.0.0.6"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,134);Page="ProductPage";IP="127.0.0.6"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,458);Page="ProductPage";IP="127.0.0.6"};
{TimeStamp=new DateTime(2000,1,1,0,0,0,846);Page="ProductPage";IP="127.0.0.6"};
|]
//this function tells me, based on a time series of requests, whether they are coming in
//at regular intervals
let timeSeriesIsSuspect(series:seq<DateTime>) =
//map the series into the millisecond component (could use ticks too)
series |> Seq.map( fun x -> x.Millisecond )
//arrange them into pairs based on sequence
|> Seq.pairwise
//filter out those where after subtracting next from prev, you get a number that mods at 100
|> Seq.filter( fun(x,y) -> (x - y) % 100 = 0 )
//get the length of those that meet that criteria
|> Seq.length
//if there is more than zero (perhaps use 1 or 2 to soften the filter) - its suspect
> 0
//this function takes the log entries, groups them by IP and Page, filters based on suspect time series
//and generates a list of IPs to ban
let ipsToBan = someTestLogEntries
//group by IP and Page
|> Seq.groupBy (fun x -> (x.IP,x.Page))
//order by number of requests
|> Seq.orderBy (fun x -> -1 * (snd x |> Seq.length) )
//check if time series is suspect
|> Seq.filter (fun x -> snd x |> Seq.map( fun x -> x.TimeStamp) |> timeSeriesIsSuspect )
//map out the IP to ban
|> Seq.map (fun x -> fst (fst x))
Console.WriteLine "IPs To Ban:"
ipsToBan |> Seq.iter (fun x -> Console.WriteLine x)
Console.ReadKey()
The difference here is that I can more clearly state, in F#, intent. Moreover, it is obvious that I can interface with others (i.e. from a database, it will be hard to write code to ban the IP) enabling me to use my "nervous system" to act on the intelligence. As well, in F#, I have available a richer set of language constructs - all the dimensions I may ever need, the ability to extend the language, etc
The only issue is that if I have a large set of data, I wont be able to handle it in memory. However, given the above, it is very likely that F# will ship with a data library (perhaps EF 2.0 - do not know for sure) - which will make it very simple to query large databases using F# without having to resort to data APIs.
Does this mean that BI, as we know it, is dead? Not by a long shot. The tooling for regular BI tied to tools that business end users can use is good, and will certainly be heavily used in the short-medium term. However, as far as what is on the horizon, BI via F# is clearly not as far-fetched as one might have thought a mere six months ago.
When people talk about lack of adoption of "XP" (aka Extreme Programming) practices, one of the chief problems people have with it is the idea of "Pair Programming". There are more times than I can count where I have been in conversations, where something along the lines of "those crazy agile guys want to have 2 developers do the work of 1 - no way we are doing agile" becomes part of the conversation. What an amazing failure of marketing. It is proof that before anyone in the software development business wants to come up with a great idea, they should run it by some people in marketing to see if the thing will fly.
Lets talk about some of the benefits of Pair Programming. When you are working with someone else, you are not:
* Surfing the web reading SlashDot/DIGG/etc.together
* Reading personal email
* Writing personal email
* Shopping on amazon.com
* Playing solitare
* Letting your ego continue to pound away at a problem that, for whatever reason, you can't solve. Your person you are pairing with should not have the patience for you to take them on "wild goose chases"
* Getting interrupted by others - people are much more reluctant to interrupt two people who are activley solving a problem than one person quietly contemplating
Rather...
* You are pacing eachother - people tend to run faster in races when they can directly work with eachother and co-motivate
* You are collaborating - two bright people should have a broader knowledge base than one single person
* You are active - walking into a team where people are activley collaborating looks like more "active" work than one where people are silently poring over their screens
* You are sharing knowledge - pairs can cross-pollenate good ideas that working alone we have to work harder to see. We seldom watch others program - and pick up from eachother little productivity habits (keystroke shortcuts, etc.)
The focus you get from pairing, so long as you are not paired with a psychopath, are immense. Pairing should generate the work of 3 people based on the productivity gains. It makes surface sense - when pairing, you are much more likely to get the 8 full professional hours per person than you are otherwise.
So why does this not sell? Seems like the benefits are pretty darn obvious. Well, personally, I believe the branding and naming of XP is one of the biggest marketing failures in history. CIOs are a conservative bunch. So are business owners. Like it or not, most of the time, they have to approve budgets, projects, and investments. Unless I have read a TON of literature and are ready to take on faith that it will work, if I am a CIO and my job depends on it, I ain't doing "Extreme" lunch, much less "Extreme Programming". I like having a BMW in the garage and not living on Ramen, ThankYouVeryMuch.
My modest proposal is to stop calling it Pair Programming or Extreme Programming. At this point, that is like calling your new energy company Enron. I propose calling it Collaborative Development. If we have two people on a project, they collaborate to get things done faster. And we leave it at that. Then, when we get things done faster and can point to good results, then we can talk about how good our new "methods" are.
It is down to these 8 :).
By all means, opinions please!
Stay tuned, another major excerpt coming this week.
Click here to see a slideshow regarding what I believe to be the 10 Commandments for the CIO in 2009.
I will give away the ending here though, as the underlying principles are as follows:
* Reduce costs – Stop spending “stupid” money. Stop throwing money at non-performing people and investments.
* Take savings from cost reduction – Invest in high ROI projects opportunistically.
* Stop pretending – Demand transparency in software development projects, demand visibility into the projected and realized return on investment.
* Your users are customers – Stop forcing software on users as though they are a captive market
* Head over heart – Being fearful and over-reacting will not lead you to good decision making. Look for opportunities to take advantage of others fear to improve your company’s competitive position.
Hunkering down and not investing when times are bad is, almost without fail, the wrong thing to do. Now is the time to re prioritize investments with a scalpel, not an axe. Play reverse robin hood - steal resources from the poorly performing, poorly managed projects - and give it to the well performing, well managed ones. And if you don't know the difference, no time like the present!
Now is the time to make line of business systems easier to use, so you can staff operations with less people and pay less for ongoing training.
Now is the time to start managing projects using agile methods, because you just can't afford faith based project management anymore (as in, I have faith that the PM is reporting the right amount of progress, versus using results that contain passing tests throughout the entire stack).
Now is the time to not only demand that projects have positive ROI, but to actually track that ROI to assure that the promise is delivered.
Now is the time to either treat IT as a profit center - a portfolio of investments in intellectual property that pay off, and outsource those elements that do not meet those criteria to others who can treat it as a profit center.
Now is NOT the time to just stop investing - both at the personal or enterprise level. The 401k investments you make now, near the bottom, are likely to have the biggest return on investment. Same is true for the smart enterprise level technology investments you are making. Assess where you are at. Unless your organizational finances are in total disaster mode at the moment, there is zero reason, other than fear, why you can't treat the current economic weakness as an opportunity to get an even better competitive advantage from your technology investments.
The easy thing to do is simply cut back, hit the IT budget with an axe, and move on to the next thing. Just because it is easy, doesn't mean its wise. In fact, the truth is usually the opposite.
Nothing like a crisis to get the mind working.
It appears that the US is going to provide investment banks $700,000,000,000 (written out for effect) to cover up for the mistakes related to their "financial engineering". This is all well and good - and has to be done, mostly because something has to be done to make sure the "counterparties" don't go broke (def:counterparty = think people Lehman Bros owed money to). That said, because of this mistake, we can ill afford to make many more.
If you looked at this through a personal lens, lets say you are a normal person. You get frustrated with real work one day, and you decide to go to Las Vegas on vacation. You discover that in Las Vegas, you can borrow lots of money and, for awhile, go along making money playing poker or counting cards in blackjack. This works for awhile (16 years) - but then someone changes the rules of the game on you (say, blackjack now pays 5/3 rather than 3/2 - or house values stop going up). Suddenly, you find yourself with all your money + all of "their" money on the table, and you draw 16 when the dealer is showing an ace. Rather than take the insurance, you decide to stay, the other card comes up (a 10), and you lose. Everything. Plus some.
What do you do now. You are like Clark Griswald at the end of Vegas Vacation. No house, no motor car, not a single luxury. You can't borrow at all - you are tapped out, nothing left but the shirt on your back.
So, after you wake up in the morning, on the street, hung over from the free drinks that the waitress gave you in sympathy, wondering what you are going to do next. Then, along comes a nice man (taxpayers), willing to give you a new $50k ($700B) loan. What do you do?
Do you waltz back into the casino? Or do you head to university and decide to stop investing in a losing game, and rather invest in yourself - that is, make yourself more productive. Maybe get an MBA, maybe become a nano-technology expert, or, at least, invest in someone else who is.
The bailout plan I am proposing is exactly that. Given we have seen what the dividends of financial engineering are, I think it is high time to stop investing so much in "financial engineering" and start to invest in "engineering engineering". Imagine a world where, in a year, we create 350k new high tech startups. So many such that even if one tenth of them work out (typical result from VCs), we end up with 35k new, prosperous companies that create really good, high technology jobs that:
* Get us off foreign oil, through more advanced green technology
* Make companies, hospitals, universities, and government more productive, through better software - in particular - better user experience, better business intelligence, better inter-operation, better maintainability
* Cuts the unemployment rate directly from 7% to 5% by providing jobs directly to around 2% of the US working population. If you count indirect jobs created because of the general stimulus, you reach full structural employment
* Through productivity enhancements and direct stimulus, puts us on an economic growth curve that rivals China
* Last but not least, helps the financial services industry because all these companies will probably need mergers, aquisitions, wealth management, etc. - think of how busy wall street was during the dotcom bubble. Now multiply that times 10.
The plan works by providing 1M of funding to any high-tech entrepeneur who has a reasonably viable technology idea and a realistic business plan. Given that 1 in 500 US adults probably has the means to develop a reasonable hi-tech idea and a business plan, you get to around 350k such companies that get funded. Enough money to take a prototyped idea to a working product. Enough money to hire 3 or 4 people and keep them employed for a couple years while the idea develops. In software, amazingly, that is enough people to get a startup going, while employing 1.4M people for a couple of years. Now here is the key... in exchange, the government gets a 20% stake in the company - and gets to put on some controls similar to what a VC would do - i.e. you cant overpay yourself, you have to have an independent board, etc, while getting away from the bad VC stuff, like stealing your good ideas and giving them to a competitor. This initial phase costs 350B.
The next phase, of course, is based on 1 out of the 10 ideas becoming viable companies that generate profit. Once you hit profitability, you become eligible for a subsequent 10M investment. Enough money to keep a staff of 10 people going for around 10 years despite what happens. Or hiring 25 over 4 years and really blowing something out. In exchange, the government gets another 10% stake - 30% total. While the subsequent stake is smaller, the chances of success are much higher.
It gets better though. After this phase, we have the private sector step in and provide the mezzanine round for the 1 out of the 10 at this level that are good enough to become billion dollar companies. The remaining 9 of 10 perhaps get bought out once a buyer is found that allows the government to realize its initial investment plus some risk premium, plus enough to cover the losses in the companies that didn't work (say, 50M). In essence, the government makes money on the deal, and the VC sector gets relieved of its duties with regard to early investments that, right now, they are too scared to make because everyone is pulling out of funds and taking positions in either "cash" or "fetal".
Think of the number of people employed here - we have 35k new, profitable, growing high technology businesses - most of which employ a couple dozen people. Businesses that are engaging in trade with the all the other non-technical businesses, making them more efficient. Actually working with hospitals to move them off paper. Making Medicare more efficient. Coming up with the breakthroughs we need in Green Energy. Doing the critical research and development needed to solve our most pressing problems.
The chief problems I could see with a plan like this are that you would flood the market with new technology - which would take some time to sort out. It would increase the supply of new tech, which if everyone chased the same business plan, would lead to pricing pressure and reduce the ability of these new companies to make a profit. Ironically, that is exactly why VCs and private equity can't do this, because most of them have a herd mentality that makes you end up with 25 different search engine companies in 1999, and 25 different social networking companies in 2007. One large investor, spreading the money around different types of business plans would help make sure that the capital doesn't self-cannibalize. Create competitors, but don't create so many that you end up with 30k of the same thing.
The other problem is that one could argue that there are not enough engineers to absorb all that money. If that is true, just reduce the scale of the investment. That said, I think the worst thing this does is take intellectual capital that is currently invested in some projects that are of marginal value - something you see in IT departments everywhere, and it re-invests it in ideas that the practitioners themselves believe in. People are always more efficient when working on something they own - and you would go from IT people who own nothing but renewable lease on a spot on an org chart, to a real company. In the worst case, you end up with a ton of engineers who suddenly have experience running a business! Talk about solving the business/IT gap! Besides, since all that works was going to India, we should have nothing to worry about, right?
This plan - which in an act of Ego comparable to Boone Pickens, I will call the Erickson Plan - will make the government money, will revive the economy, and will restore our position of leadership in the world - investing in the intellect and inventiveness of our people, rather than in the faith that giving money to wall street will solve our problems. It will demonstrate to the world that we are serious about competing. It will probably cause other nations to make similar investments in their own economies, just to keep up. It will deploy capital towards where the IQ points are, rather than simply where the best K street lobbyists live.
I can't think of a more win-win arrangement than that!