Tuesday, August 10, 2010

Here and now, here and now…

For this exercise, imagine you are are a Director in a large corporation.  Directors are the folks who have budgets that they allocate in their area of responsibility.  They are measured by the results they get from their budgets.

Now, resources are always limited, sometimes more than others, but always limited: we can always, and do, imagine more good things to do than we are able to accomplish.  Dreaming, having thoughts about how to make things better, is part of what makes it worthwhile to get out of bed in the morning.

And thus it is that Directors have to make decisions about budget allocation.  So imagine the situation: you have 6 products.  One has 2 million customers.  Another has 1 million customers.  And the rest have a few thousand each.  Where are you going to put your money?

The Fallacy of Now

“Here and now” is a great mantra for paying attention to what is going on around you.  Try taking a walk around your neighborhood by yourself, saying “here and now” over and over again in your head, as loud as needed to keep other thoughts out, but as softly as possible.  You will notice things that have been there all along, but which you otherwise would have missed.  Colors, sounds, smells, movements of leaves and animals will jump out at you in a way that you are likely to realize is foreign to your everyday existence: we have a tendency to live in our heads rather than in the world around us. The mantra clears what is in your head, with the result you notice what is always there to notice.

OK, but what about allocating budgets?  Does “here and now” work for allocating resources?  Define “now” (amazing how those immortal two words of Bill Clinton still live on in the culture, isn’t it?).

If “now” is defined as “how many customers use each product” then the answer is one thing (starve the weaklings until only the strongest survive).

If “now” is defined as “how many potential customers are there based on current customer information?” the answer might be quite different (the number of customers likely to adopt).

If “now” is defined as “what mix of products will force the product teams to improve their products the most to meet the unknown needs of the future” the answer might be quite different also.

The Fallacy of Non-domain Management

Of the 3 ways of defining now described above (and there are surely many others), the first two (# of customers, and # of potential customers based on customer characteristics) are the easiest for a person who isn’t expert in the domain to use: they can be backed up by numbers.

To answer the third question, looking at the product mix in terms of creating the setting for creativity in meeting the future, one has to either be a domain expert, or rely on non-toadying domain experts, in order to reach a decision.  Having a vision of the future requires the kind of knowledge we call domain expertise, and probably requires domain expertise of long-standing.

Take Ford, For Example

You might have noticed that Ford Motor Co. escaped the auto industry meltdown.  How did they do it?

The answer, I’m sure you realize (why would I bring it up? <s>) is vision, preparing for the future today.  When Bill Ford took over Ford in 1999, he pushed the company to look forward, to develop the cars of the future.  Yes, the company took a hit on profits (and he was forced out in 2006), but it prepared the way for the current president, who is good at production, to have a success producing cars whose design was started under Bill Ford’s watch.  Bill Ford was, of course, a domain expert of long-standing.

Of course, this isn’t a great example of how to succeed in business: disappoint the bottom line and you’ll be looking for a job, and not have all that Ford stock to fall back on.  And that brings us to yet another example.

Take Microsoft, For Example

Microsoft has recently eliminated support for IronRuby, according to a blog post by Jimmy Schementi, who was one of two people working on IronRuby.  He has gone to Wall Street where he will, I’m sure, make his fortune.  Good for him.

Historical note: Microsoft announced that IronPython, IronRuby and IronJS would be first-class languages in .Net less than a year ago.

This is not surprising from a company that did not have the vision to bring Visual FoxPro to .Net (first saying it could not be done; then saying nothing when it was proved to all that it could – and that was back in 2005).  And it is not surprising from a company that squandered 10 years of Windows Mobile development because they wanted to serve the customers they had, who all knew to work in Windows, and so they designed it like Windows.

Ask The Right Question…

… and at least you have a chance of getting the right answer.  If the Director (whatever they are called at Microsoft) who allocates budget for the languages team asked the question “which languages have shown the greatest productivity for programmers” the list would certainly include Ruby, Python, JavaScript and Visual FoxPro.  Note this is an issue of quality, as much as quantity.  The question could rightly be phrased as “which languages have the quality of making programmers productive?”

Why look at productivity rather than other criteria?  Simple: productive programmers succeed in the marketplace, which means they will be left standing at the end of the day, as it were.  Some of these will be professional programmers, who do it for a living.  Some will be semi-professional programmers who write software to run their businesses:  things like manage nuclear plant construction, invest venture capital, and run a plating (think: chrome plating) company, to mention three semi-professional programmers I know.  Some will be domain experts who need a productive language and tools to create products for niche markets, i.e., Independent Software Vendors (ISV’s), like several that I know.

The Right Questions Start At The Top

I don’t think this requires a great deal of discussion: Directors will only ask the right questions if the right questions are asked at top of the corporate hierarchy.  Otherwise they will ask the questions that are the easiest to back up with numbers, things that have quantity.  Which of course leaves out questions of quality.  And if questions of quality are not asked, the answers reached are unlikely to lead to quality.

10 comments:

JBWild said...

Very meaningful words there Hank. I have been a follower of Microsoft wares for decades and refused to 'get too close' even though I have MS certifications, etc. My wife even works for them. I have seen a shivering shift in their company that has roots made from the 'little people'. Their products have shifted to the larger corp and now the 'cloud' is at hand. Their focus is on recurring revenue like the carriers, etc. without it, who knows what can happen. Being so 'loyal' if felt a hard slap to face when the curtain came down on such an amazing product VFP. I will never forget it. I am a 'little people' but I stood by them and faithfully used their products for decades. I feel like the tiny bug that was not noticed in your walk around the neighborhood...

Hank Fay said...

Thanks. Yeah, there are times I get that squashed feeling.

Thich Nhat Hanh (Vietnamese Buddhist Monk, a member of the peace team that negotiated the Paris treaty ending the Vietname war) reminds us that we must nourish our roots, or we will wither. It takes a near-disaster for most companies to remember that simple truth. Sigh.

Pertti said...

Nice take on recent developments, Hank.

As "little people," we are at the mercy of the software industry, which we simply cannot control. And neither can we, as individuals, really control open source software.

So, while we can look at the sky and say "I wish it wouldn't rain, I wish it wouldn't rain," there is precious little we can do about it when it actually does rain.

So, just like with VFP, the apparent demise of IronRuby & IronPython are events that we simply must weather (sic!) At the risk of oversimplifying the weather methaphor, I think we must each figure out for ourselves where the best weather for our crops are, and then move there, regardless of what anyone else says.

I personally don't want to jump into some open source LAMP stack because those are usually poorly supported, especially over time. In a LAMP stack there are too many pieces that must be plumbed and fitted together for the total software solution to work. So for me at least, going with a system that is supported by a large software house, such as Microsoft, is a given.

Until Visual Studio 2010 I didn't see many good (or pleasant) alternatives to what I was already using (VFP), but now the VS platform FINALLY seems rather solid and relatively easy to use for creating line of business applications. I still find that I need to build my VS 2010 applications on top of a third party framework in order to get the smoothest end user experience and the fastest development time, but this was the case with VFP, too.

While I am no Microsoft Fan Boy, I don't see too many good alternatives out there. Specifically, I don't see C# and/or VS going away in the next 10-15 years, which is longer than I really want to continue working in this field anyway, so that's the basket where I'm putting my eggs today.

Given its corporate history, I can't take Microsoft on its word about anything, really, and that's why I will not even try to use anything else that MS might be pushing, such as IronRuby.

Too sad, too bad that it is raining, but at least I feel that I have a passable shelter to weather the storms that are sure to keep coming.

Hank Fay said...

Agreed, almost. <s>

Agreed that it is folly to trust the discernment process in a large corp., because it is distorted by the nature of it being a large corp. Only a powerful leader can make a difference: Apple screws up, but it's in the right direction for the most part. But their development tools suck, too.

Agreed that C# and VB.Net will be around in 15 years, in some form. And that's about my timeframe for continuing to work (strange to think about work ever being "over").

All that said, I am still a proponent of productivity of a kind not available in VS2010/C#. The frameworks, both MS and 3rd-party, all miss the point.

I'm also a fan of making code readable, and keeping down the clutter in my mind as I develop. That's the reason for me to look elsewhere.

One of the consequences of MS's decision to cast off IronRuby, and put resources in IronJS (likely at the expense of IronPython -- Jimmy Schementi was active on the IronPython mail list, and in its development from what I have read), is that 3rd-party products look better in comparison. Between a volunteer IronPython and a volunteer Boo, Boo comes out pretty good on a couple of counts. First, there is corporate support (Rodrigo now works for Unity (the game development too), who use Boo as the basis for their scripting language), and second, there is a track record (5+ years) of continued progress using volunteer effort without corporate support.

OTOH, if VFP.Net were to come alive, I could arrange multi-company support for it, also, making it credible in the process.

And my reason for searching out credible (open source = credible when there is corporate support, according to the latest analysis of open source projects) alternatives is because MS has shown very little interest in helping along the kind of productivity I, and my employer and clients, need to have in order to thrive in the marketplace.

And for most folks, whose marketplace success does not depend on Boydian (maintain acceleration in a curve) productivity, the tools MS provides are just fine. From a selfish perspective, I like that: it clears the field for those of us working in more productive environments.

johnf said...

I see your efforts somewhat a kin to the hybrid car. You don't want to give up MS (gasoline) but you want be open source (the electric). Yes I understand that you want to be more productive - we all do. But tell me what are you giving up by completely dropping MS products? Is using plain python really not a solution that can meet your needs. You already have to create a new framework for your work. So what does .Net really offer?

Hank Fay said...

Hi JB,

that's a good question, that has to be asked: what is the benefit of staying with MS, given one's choice to gain security with open source (how to do that: coming in the next Blog Post, in development)?

The answer has to do partly with marketing (acceptability to mid-range companies, who don't do open source, have limited IT staff, etc.); and partly to do with, as Pertti mentioned, having an infrastructure that will remain supported (although one can be certain it will evolve, and require adjustments over time -- take the former MSMQ for example).

Marketing, of course, trumps technological consideration. What if I wrote great software and nobody came? I don't have a big enough yard to grow enough corn to do Field of Dreams. <s>

Technologically, .Net has a rich infrastucture, especially in the area of user controls and reporting engines. Having all that available makes life that much easier.

So that's my answer to a very good question.

Hank

Hank Fay said...

Oops: JF, not JB. Sorry about that.

Vfp likes me said...

I found an article about .net microsoft.data.dll.
This was introduced by webmatrix project with razor scripting.
The ideea of a local engine was not bad. If ms would provide a mechanism of automaic filling the sdf file when quering a server we could move on more easly. We could query using sql that sdf container in a maner appropiate to vfp. I wrote a comment about this, but i think ms ears need a doctor. And unfortunately neither in java there is not a decent way when deal with data. While in java it is understandable, to ms it is not, because vfp was born in their garden.

Here is that post if you are interested

http://sondreb.com/blog/post/Trying-to-understand-MicrosoftDatadll.aspx

Pertti said...

Hank --

It is really interesting how so few, if any, development platforms use metadata from the ground up.

Point in case: Just today someone came to me and said that they need to make a small change to some 100+ VFP reports that they have painstakingly constructed over time. I had written this system so that they could generate "child" reports from the "mother template" report and tweak them slightly to fit the specific "child needs." Ideally I would have used inheritable reports (RCX class -based as in VCX for objects) from the get-go, but since I didn't/couldn't, I can STILL make a global change to all those 100+ reports by writing a simple program that will manipulate the FRX -files just so in one pass.

After all these years of Fox, why oh why don't software tool development houses still seem to get the essentially metadata -driven tool architecture? It makes life so easy and tools so expandable that it is almost laughable. Actually, I for one am laughing all the way to the bank after changing those 100+ reports in one swell swoop, and my client is laughing while writing the check for this job, because the price/report is so low.

This would have been part of the beauty of VFP.Net, had it ever truly materialized.

Hank Fay said...

@VFPLikesMe

re: Microsoft.Data.Database

I'm glad you gave attention to it. It's a strange beast: it implements IEnumerable, but has methods consistent at least partly with IQueryable.

I've written a little bit about it: http://groups.google.com/group/the-prosysplusnet-framework/browse_thread/thread/7e3bf1805b035b7c

What Ayende doesn't include in his thinking is what Pertti mentions: metadata. It's not like all the business rules are being thrown out: they are being kept where data should be kept. In a table. <s> At least until being dynamically compiled into an assembly with the same name you've selected for the "view" (client side, able to be dynamic).

Some brilliant people, like Ayende, have disparaged (or worse) Microsoft.Data.Database. Even brilliant people may not know all the options: they are brilliant with the options they know.

Hank

PS: I went back and also looked are your article on Unity (IOC framework, not the game development framework). You realize that's a framework you only need if you can't pass a method as an object, right? As you can do in Boo? <gd&r>