Aaron's Technology Musings

Pair Programming - Marketing FAIL

2008-11-19T16:47:00Z

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.

Cover for The Nomadic Developer

2008-11-10T20:34:00Z

It is down to these 8 :).

By all means, opinions please!

Stay tuned, another major excerpt coming this week.

10 Commandments for CIOs in 2009

2008-11-03T13:39:00Z

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.

A 700 Billion Dollar Bailout Plan that will Actually Work

2008-10-21T13:53:00Z

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!

MetaLinq Update - XmlSerializer Support

2008-10-16T00:52:00Z

Ido Flatow has updated MetaLinq to include a very cool feature - namely, support for serialization of expression trees to XML.

Basically, this feature allows you to specify an expression tree using XML, read it in using MetaLinq, and go on to execute it in the context of a program that might understand said tree. And this is jus the start. When you think about the possibilities that passing around and executing expressions enables - it opens up some real intriguing possibilities. Think persistent storage of business rules that are expressed as Lambda expressions.

We are in beta testing for this feature, which you can download from http://codeplex.com/metalinq. Take it for a spin - and dont hesitate to contact me if you have questions about the feature.

The Nomadic Developer Book Excerpt - CHEAP Consulting, the 3rd Deadly Firm

2008-10-03T23:02:40Z

This is a book excerpt from my upcoming book, "The Nomadic Developer". It is in a chapter titled "The Seven Deadly Firms", which includes elaboration on two previous firms, FEAR and BOZO, as well as several others you will need to buy the book to learn about.

While a body shop tends operates in the world of low-cost contracting, CHEAP Consulting executes entire projects using hordes of low cost developers, rather than small numbers of good ones. Ironically, this makes their projects, after all is said and done, come in far more over budget than the firms they competed with in the first place.

CHEAP Consulting takes advantage of the tendency of some organizations to buy services based on rate-per-hour, to the exclusion of all other considerations. This frequently occurs when the agent purchasing professional services is separated from the person who is responsible for the outcome of the professional services. In such a case, the former (often called a vendor manager) is compensated on getting average hourly rates low, and does not have a meaningful stake in project outcome. The latter – often a development manager – is left with the results and often lives a very frustrating existence trying to get useful software built using the lowest bidder per hour.

This scenario occurs because there is a mindset in some quarters that a developer-hour is a universal unit of exchange in software development. Of course, history shows us that the output of one developer-hour of a person with a particular skill set can vary drastically from person to person (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000). However, despite all this overwhelming evidence to the contrary, there are some organizations that continue to be blind to this reality, likely as a result of the influence of a long tradition of thought in industrial engineering – starting with the work of Frederick Taylor - that seek to minimize variation in personnel performance.

Life at CHEAP Consulting

The main feature of CHEAP is the heavy use of the word resource. More than any of the seven deadly firms, at CHEAP consulting, the fact that you are one resource of many, pluggable from one project to another, is the chief feature of this firm. That said, life at CHEAP isn’t bad, per se – this isn’t FEAR where the goal is to keep you there by sheer intimidation, nor is this BOZO, where the projects that are sold usually end up being done for a loss. If anything, CHEAP consulting is a place where you do mediocre projects for mediocre money for mediocre companies.

The problem for consultants at CHEAP is that the work is of low value, requires comparatively low skill, and frequently features technology several generations behind what would be considered current. Conformity is a core part of the culture at CHEAP. Because of this culture, the primary attributes that cause growth of a software developer, chiefly using the creative urge to overcome technology problems, tends to be selected against.

This, of course, is just fine if your main goal in life is to simply collect a paycheck and put in your time. And for people for whom software development is merely a means to an end, working for CHEAP is a perfectly acceptable solution. At least for awhile.

The problem, however, is that if you become a commodity, you become very easy to outsource. The kind of work done by CHEAP consulting can also be done very easily anywhere in the world. Thus, the main problem with CHEAP consulting is that it becomes CHEAPER consulting over time. Thus, over time, your ability to make a consistent living becomes more and more difficult, and you are constantly prone to job loss.

Which gets to the next feature of living at CHEAP Consulting – constant fear of being outsourced. Because you know you are a commodity – unless you are blissfully ignorant of what is going on around you, you likely lose a lot of sleep that your consulting gig will be shipped to India, or nowadays, somewhere even less expensive than that, such as China or Vietnam.

Lastly, the salaries at CHEAP consulting represent where this firm sits in the marketplace. Because they compete on price, it is highly likely you will be in the bottom 25% percentile of wages for your given skill set. Furthermore, advancement is going to be slow, and because you are working on technology several generations behind what is current, your ability to market yourself is going to be limited to other similarly situated companies. It becomes something of a downward career spiral that can be tough to recover from.

Signs You are Interviewing at CHEAP Consulting

If job ads in consulting came with salary figures attached to them, it would be real easy to know who CHEAP is. Unfortunately, rarely is this the case. As a result, you have to look for the signs that point to what will ultimately be a low job offer.

The first thing to ask that should give you an initial sign you might be at CHEAP consulting is to ask the prospective firm how they get business. CHEAP consulting tends to get business through what are known as vendor management programs. Now, not all vendor management programs are bad or dysfunctional, but many are, and seeing a prospective firm primarily working through said entities is usually a sign that such a firm primarily competes on price.

A second thing to look for is to ask what technology you will be working with. Of course, this can be difficult, because the technology stated in the job ad can describe what they want you to know, which frequently has nothing to do with what they want you to do. The actual work you are doing may end up being on technology several versions behind what is current, which is a good indicator you are working for this kind of firm. The question to ask, then, is “what kind of technology will I be working with on day one?” The manner in which this question is answered should tell you a lot about this firm.

Prognosis

I would like to think this kind of firm is likely to fail over time, but cynically, I suspect that there will always be people who believe that people are “plug compatible”, and thus, will have services purchased at the lowest possible price. Especially because there is always going to be a sector of this business doing work with only marginal economic value (higher than zero, but not by much), there will always be a place for this kind of firm. Given that there are some firms like this that are some of the largest firms out there, the economics are going to dictate that these firms will stick around.

That said, while such firms may be good stock investments, they are lousy places for creative minded technology professionals to work. While marginally better than the more dysfunctional cousins, BOZO and FEAR, it is, nonetheless, not somewhere that most people will ever go to work for on purpose.

New MVP Awardees

2008-10-01T15:37:00Z

This morning, I received word that two of my colleagues in Chicago, Ben Cline and Anthony Handley, both were awarded MVP awards.

Ben Cline is a master of BizTalk who spends a lot of time in the MSDN forums helping people untangle issues. Earlier this year, because of his participation, he became named a forum moderator. Seeing him get the nod is really neat, given he has achieved his award mostly through forum work - "old school" as they say.

Anthony Handley, who alongside Corey Miller, leads the Chicago Designers and Developers User Group, also got the nod, for his great work on his blog and in the community in general. It is really cool to see UX people getting into the program.

Congrats to both!

(oh, I got extended too :) )

F# Business Intelligence Case Study - XBox Live Trueskill

2008-09-07T19:36:00Z

Some time ago, I speculated that F# should be the lingua-franca of BI.

Well, had I done a little research, I would have found out that people are already doing BI using F#, namely Microsoft. On a recent podcast of The Thirsty Developer (to be published soon), some colleagues and I were talking to some members of our local evangelism team when Jason Bock told me that TrueSkill was implemented using F#. To which, I reply... that sure sounds like Business Intelligence - or something like it!

Since I am making yet another audacious claim, perhaps an explanation of what TrueSkill is would be helpful.

If you play XBox 360 and Halo, you are probably familiar with the concept of TrueSkill, which is used to measure how you compare against the bell curve distribution of other players of a given game.

As for the BI part, the analysis task of TrueSkill is to go over the following:

* Multiple terabytes of matchmaking log data

* Data spread over 11,000 text files.

* ETL'd into SQL Server

* Use of F# to do calculations on this massive database to determine TrueSkill rankings for players

We are probably not talking about simple averages and things you would do with a cube here. The resulting solution, as I was able to ascertain from a blog post by Don Syme, was about 100 lines of F# code to create a production version of this that runs as an ongoing task.

Now, if we replace customer records with XBOX Live log entries, I think we are onto something here - especially for more complex and/or scientific scenarios. Imagine, rather than TrueSkill, we used this to estimate, say "TrueLikelihoodToUpgradeFlights" so we could help airlines deploy better upsell opportunities.

But the bigger point - one pretty much demonstrated by this whole scenario, is that there is no reason - none. at. all - that BI has to be a database technology. BI can come from anywhere, and the best tool for doing the job in BI is functional languages, due to how functional languages makes the task of writing massivley paralellizable code a great deal simpler than other imperative languages do. Sometimes that language is SQL, and it's database oriented BI variants - and sometimes, as in this case, its F#.

It is high time we stop treating business intelligence and software development as if they are different things. They really aren't.

Update: Ralf Herbrich from Microsoft has provided some more links for some of the background:

* Slides and presentations of an ICFP 2007 talk by Phillip Trelford on the application of F# for TrueSkill ()

* A presentation of the mathematics and tools used in the TrueSkill analyses at KDD ()

* An F# implementation of TrueSkill at our blog

I Promise To, Never Again, Estimate By...

2008-08-18T16:53:00Z

* Screen Count

Leads to the idea that Google.com can be replicated in 2 days if you can knock out 1 screen per day. Not all cases are Google, but seriously, estimation by screen count is a horrible idea.

* Number of Objects/Classes

For one, it implies you know the design up front, which as we know, we almost never do. This is especially true since I tend to be writing estimates during and/or prior even to doing requirements, and therefore, speculating what classes and objects we will have and estimating them is the pinnacle of silliness. Don't do it.

* Number of Database Tables

Like the above, but even worse, unless the app is total CRUD, in which case, you should be using MOSS/Infopath of some other generator technology.

At the last Chicago alt.net user group meeting, Bobby Norton* of ThoughtWorks moderated a fantastic discussion after his presentation on Cruise. I am told we will soon have video of this conversation, but the essence was that we all have estimation FAIL on our resume, and we need to get better at it. My big question, which is what I alluded to in a previous post, is that I am curious about how people actually do agile estimation. The whole idea finally clicked for me that has been around for awhile - estimate by user stories (think use cases, only different), assign "story points" for use case complexity, and if a use story is above a certain "story point" threshold, break down the story into something more manageable.

This is different than screens based estimation because IMO it does a better job of capturing the complexity of a screen when you are talking in user understood language. One screen may happen to be the place where a user will experience a great variety of stories. It also gets away from enumerating the design prematurely - as it states things from the perspective of the user, without trying to assume what artifacts are going to be developed to meet that complexity.

The real benefit, though, is on the measurement side. The key metric is how accuratley a given estimator can pin story points to complexity. Once you are storing information and graphing it - so you have some history about how much time goes into, say, an "Aaron Erickson story point" or a "Your Name Here story point", you get better at being able to predict what you can accomplish in a given time frame.

Is it perfect? No. But remember the word we are using here - that word being estimation. By continuously improving your estimates by using evidence of accuracy in the past to guide your future estimates - you do your client a great service. You have evidence you can base your estimates from, which in turn, gives you the real "predictability" you are looking for.

Evidence based estimation is where, I believe based on, well, evidence (HA!) the world is going.

* Apologies, got my thoughtworkers confused last time

Fall 2008 Speaking Schedule

2008-08-18T16:37:00Z

A quick update of what I have going on for the speaking agenda.

* Michiana .NET Users Group, South Bend, IN, Aug 19th, "F#, The Business Case"

* Codeapalooza, Sept 6th, Chicago, IL, "Super-Optimized LINQ - Indexed Objects"

* ACM: Chicago Chapter, Sept 10th, Chicago, IL, "Microsoft's F# - Functional Programming meets the Mainstream Software Developer"

* Twin Cities Code Camp, Oct 11th, Minneapolis, MN, "The Intersection of F# and LINQ"

* VSLive Las Vegas, Week of Oct 12th-Oct 17th, Las Vegas, NV, "F#, The Business Case" and "Super-Optimized LINQ - Indexed Objects"

* Lehigh Valley .NET Users Group, Center Valley, PA, November 17th, "F#, The Business Case"

* Austin .NET Users Group, Austin, TX, December 8th, "Indexed LINQ"

Check this thread often, as schedules over this timeframe can change. As always, my favorite parts of being in this business is getting out and meeting people.

Introducing "The Nomadic Developer" - Surviving and Thriving as a Technical Consultant

2008-08-12T21:21:00Z

I am very pleased to announce that I am now officially writing a book, through Addison Wesley, about ins and outs of the technology consulting business. The best way to think of the book is as an operating manual for your career as a technology consultant.

My motivation for writing a book like this is, frankly, I want consultants to understand this business, so they can make better career decisions. Decisions about where you work (aka don't work for BOZO, FEAR, or other swindlers) - how you get paid, how clients select consultancies, how the sales process works, and really, what makes a place like Magenic, or any other consultancy, tick.

It is an ambitious effort, to be sure. And the schedule is aggressive. We are hoping to have a book out in stores mid-2009, which in book publishing, isn't that far away, given I need to have a manuscript done at the end of January.

Here is my current plan for my table of contents. Note that this is very tentative, but should give you a sense for what this is going to be about:

Chapter 1: Going to battle

Chapter 2: Why consulting?

Chapter 3: The consultancy taxonomy

BOZO Consulting

Somewhat bumbling and conservative, yet makes a practice of selling dollars for eighty cents and expecting the consultants to pick up the slack. Nice people who, generally, are not going to go very far or expand beyond their core market.

FEAR Consulting

Manages consultants by fear – uses tactics that Machiavelli would blush at to keep consultants in line. Biology – that is – bathroom breaks go on your time report. You would leave, but your self-esteem is so low from working there, that you don’t.

... and so forth, you have seen these entries before... look for a dozen or so more :)

Chapter 4: The secret guide to how geek consultancies work

Chapter 5: Getting in – secrets to what consulting firms look for

Chapter 6: What you need to ask before you join

Chapter 7: Surviving

Chapter 8: Thriving

Chapter 9: Some Typical Career Arcs for Technology Consultants

Chapter 10: The Payoff

Chapter 11: How to know it’s not for you

Chapter 12: Thoughts on Consulting from Real Consultants

Appendix A: A Consulting Lexicon

The deal is done - now the big task is actually writing about 11 more chapters, an appendix, and generally, making it worth your time to purchase and read. Now the hard part.. getting it all done and written! I will say that it is an honor among honors to get a chance to not only write a book, but to get to write one on a topic that I am this passionate about.

Agile Estimation?

2008-08-05T01:42:00Z

If you can't write a design until you write some code, how do agilists (or agilistas - you decide where you sit) - do estimation?

I am really curious. I have, and do, do the COCOMO thing, function points, and other techniques. Occasionally, if I think the app is CRUD enough, I go down to "screens" based estimation... but more or less, I am interested in the details that drive you to think "40 hours" versus "8 hours". And if you are doing agile and TDD, how you can ever come up with an estimate at all, at least before you write some tests which allow you to know... perhaps... what classes, and even more perhaps, what the FP of those classes will be, in your estimate.

I ask this not because I think estimation of effort up front is a good idea. Largely, I think, it is a guess that we do given the information we have at the time, which, more often than not, is usually insufficient. But every agilista is making a living, and if you are doing so, the people that, I dunno, pay you, are asking how long you think something will take, even before you have written the HOLY tests.

Just curious... cause I am stumped.

Charity Fragathon

2008-08-01T15:57:00Z

My friends and colleagues Chris Williams and Jason Bock - with the graphics/UX help of Anthony Handley - are putting on an event that can only qualify as EPIC.

No, its not yet another user group, code camp, or something like that. No, this one is strictly fun for charity - that is - Charity Fragathon.

If you can be in Minneapolis on September 24th, you should definitley go. If not, at least a donation will help. Magenic is matching the first 3K donated.

Unit Test Framework for Silverlight: UnitDriven

2008-07-16T11:58:00Z

Some of my colleagues at Magenic, Justin Chase and Rocky Lhotka, have developed a very nifty framework for unit testing Silverlight apps - UnitDriven.

In particular, it is optimized for testing asynchronous code in Silverlight, which is virtually impossible with existing unit test frameworks - both from Microsoft and elsewhere. More details are available from the CodePlex site.

What the F#? - Role of F# in your Future Development Plans

2008-07-08T01:27:00Z

Video: What the F#

In this video from TechEd Online, recorded at Teched last month, Amanda Laucher (aka Pandamonial) and I talk about what F# is, why you should care, and why functional programming matters.

In an amazing coincidence, Amanda happened to have printed a F#TW t-shirt (i.e. F# For The Win, for those unaccustomed to the meme) - which is particularly ironic given that is an anagram of our interview :)