I like this quote from General Stanley McChrystal on crisis communication:

“I think when any leader faces crisis, this is true on the battlefield but I think it's also true in other areas as well, one of the things you fear most is not understanding the situation. And I think it's that uncertainty that actually is most unsettling to many leaders and causes them to be undermined in their confidence.”

Understanding the situation. If you lack context. If you lack critical knowledge. You cannot effectively lead. First, seek to understand. Listen and absorb. Contemplate. Then, and only then, act.

If the Bard had written in C#:

public class Self 
{ 
	public bool ToSelf() 
	{ 
		return true; 
	} 
}

I’m fascinated with the subject of meetings. It is a topic of discussion across the wide webbed world. There are nearly as many opinions on this subject as there are stars in the sky. So adding my own here cannot possibly disrupt our little corner of the multiverse, nor will it likely establish a new or even affect an existing trend. But before I bore you with my own opinion, let me share with you some links to some very cogent resources that have helped me, in addition to my own years of experience, to form my opinions here.

• Firemen, donuts and meetings – Seth Godin: “Don’t bother to have a meeting if you’re not prepared to change or make a decision right now.”
• Reduce Meeting Time by 30 Percent – Max Isaac: “Prior to the meeting, send an email with the proposed Purpose, Process and Preparation, and attach documents that should be reviewed.”
• Meetings frustrate task-oriented employees – American Psychological Association: “…people high in accomplishment striving, who tend to be highly task and goal oriented, were most negatively affected by meetings...
  ...people who participate most in meetings, such as those who identify themselves as upper-level management, tend to view them most favorably...solely because they get to talk a lot, they inevitably miss other key pieces of meeting effectiveness, including their ability to successfully lead the meeting.”
• Why Goal-Oriented Requirements Engineering – Yu & Mylopoulos: “The identification of goals naturally lead to the repeated asking of "why", "how" and "how else" questions... Stakeholders also become more aware of potential alternatives for meeting their substantive goals, and are therefore less likely to over-specify by prematurely committing to certain technological solutions.” (This paper is not about meetings but contributes to the opinions expressed below.)
• Goal-Oriented Idea Generation – multiple authors, taken from summary of results: “The goals obtained from the ideas have high quality. During the activities for grouping ideas, it was frequently observed that the stakeholders could find their misunderstandings and tried to resolve them. As a result, the obtained goals were based on the consensus and the agreement of all of the stakeholders.” (Again, this is not about meetings but contributes to my ideas on the subject.)

It has been my experience that any form of software development, including my personal favorite: behavior driven design/development first introduced by Dan North, generally requires more than one person in the process. There is at least a user and a programmer, at least for any software that one might be paid to produce. And where there is more than one person in a process, there is the inevitability of a meeting.

The real question is what is the nature of the meeting. And by nature I mean how will it be planned and conducted, and what if any follow up will occur as a result of the meeting.

Bad Meetings: Vague, Purposeless, Meandering Time Wasters
The world of software developers could fill terabytes of hard disk space with examples of meetings that were a complete waste of time, ineffective, resulted in no change to the status quo nor the discovery of anything that was not already immediately discoverable in an issue or project tracking system.

Rather than go through any of these bad examples in detail, I will simply summarize that these meetings most typically include in the email invite only a vague subject line, a time and place, a dial-in number for remote attendees, and by virtue of the most commonly used tool to send the invite, a list of attendees, most often the entire team. Too many of these meetings and your organization has fallen hopelessly into the “Meaningless Meetings Machine.”

Goal Oriented Meetings: Purpose Driven, Limited, Action Packed
The very best meetings I have ever attended or conducted (yes, I’ve conducted my share of bad meetings too) have had the following qualities:

• Goal oriented – the agenda focuses on stated goals. (See Mark Schiller’s cogent treatment in Fixing IT Productivity Destroyers.)
• Limited scope – the time and agenda are limited to specific related goals.
• Parking lot – good but unrelated ideas go into a “parking lot” to be discussed at another time and often in a different forum.
• More listening (less talking) – participants listen carefully with their full attention and speak only when they have something relevant to contribute or need clarification in order to make a decision or understand an action item being assigned to them. And NEVER, NEVER, NEVER do participants rudely talk all at once.
• Previous action items related to goals on the agenda are reviewed in summary fashion – discussion is limited to reporting outcomes and/or impediments that require attention by the group. This does NOT mean that the group attempts to resolve these impediments during the meeting. They are noted and may generate an action item for a participant, but under NO CIRCUMSTANCES will the meeting get side tracked to solve the problem in the moment.
• Goals drive actions – starting with diverging opinions and working toward consensus in these steps:
  • affirming the goals are properly stated
  • identifying actions required to achieve the goals
  • identifying (or getting volunteers) to take those actions
• Decisions are made – work toward a consensus but have a meeting leader who can make a final decision right there, right now, after having considered the input of meeting participants. Perfect consensus is not the goal. Decision and action from team input and reasonable discussion is sufficient. (And as Seth points out, don’t bother having a meeting unless you are prepared to change your mind. If you have already made your decision, just announce it, assign the tasks and follow through—don’t waste your team’s time with a meeting to maintain the illusion that you care about what others think—they know you don’t.)
• Minutes, including action items and commitments, are recorded and published post haste. They are also maintained in a team public place such as a wiki or project portal for reference and follow up.

Goal Oriented Meetings Foster Better Software Development
I included some links already that talk about goal oriented requirements engineering and behavior driven development (BDD). In Dan North’s treatment of BDD, he presents two single sentence templates for defining each of the requirements of any software system. With my own explanations, they are:

To define a feature or user story:

As a [X], I want [Y], so that [Z].

Where [X] is the role of a user, [Y] is the feature, and [Z] is the benefit or value (the goals) of the feature.

And to define the acceptance criteria for that story:

Given [some initial context—the givens], when [an event occurs], then [ensure some outcomes].

The outcomes to be assured also define the goals of the user specifically within a certain behavioral or system state context.

When the goals of stakeholders are clearly understood and can be codified in a manner such as the BDD form, the development team can move forward more quickly and with greater confidence. And when meetings are equally focused on goals and achieving them, meetings will be an asset rather than a liability. And your team will have a much greater opportunity to succeed.

December was an interesting month with multiple pieces on the chess board moving all at once insuring an interesting and exciting new year for me. And that new year is upon us. I picked up my copy of CIO Insight magazine, the November/December 2011 issue, this morning and read with delight the article entitled Where the IT Dollars Are Headed in 2012.

One passage in the study mentioned in the article (included in the print version and linked to online) caught my eye:

“Elsewhere in enterprise applications, collaboration, and content and project management are rapidly gaining popularity, which makes sense given the new mobile opportunities for these categories. Collaboration and content management are seeing increases in 2012 over 2011 of roughly 10 percentage points in the number of organizations budgeting; and among those that already were spending in these areas, budget growths are averaging 14.6 percent and 7.3 percent, respectively—both significantly higher than 2011’s growth.”

I have a recently renewed and very keen interest in the potential growth of the enterprise content management market. And I will blog more about this in the coming weeks which are sure to open up new opportunities for personal and professional growth.

A friend recently shared a Forbes article with me entitled Top Ten Reasons Why Large Companies Fail to Keep Their Best Talent which I found informative and useful in understanding my own recent thoughts on this topic. Rather than review each of those reasons here, I encourage you to read the original. Instead I would like to share with you the flip side of that coin based on my own recent experiences.

Attracting Top Talent
Before you can work on keeping your top talent, you have to find them and convince them to join your team. Here are five things you should be doing to attract top talent:

1. Choose a competent and effective recruiter. This can make all the difference. Don’t just hire an agency and let them blast a job description to every Tom, Dick and Mary of the tech world. Know specifically who is representing your company. Make sure that she knows how to find and filter top talent for you. Ensure that she has the communication and people skills required to manage the phone and in-person interviews and coordinate with the hiring manager to make his job even easier rather than just dumping a pile of resumes on a desk and waiting to get paid.
2. Do more than one phone screen. Give at least two top team members the chance to phone screen the candidate. Make sure they are prepared and understand what they should ask. Then have one or two managers or potential peers conduct a phone screen as well. Never rely on the resume alone to decide whether you will do a face to face interview.
3. Have the candidate interview with more than just the hiring manager. Have potential peers and even potential subordinates interview the candidate as well. And when possible, have a peer or supervisor of the hiring manager conduct an interview. Meet with and collect the thoughts and opinions of every interviewer and carefully consider their input.
4. Assure that every interviewer is positive and upbeat about your company but equally honest and transparent about the challenges and opportunities within the company which the candidate may be able to help resolve or improve. Don’t paint a dismal picture but don’t put a shine on a dull spot. Any intelligent candidate who gets different stories from interviewers will think twice before accepting an offer. Transparency and honesty from the bottom to the top of the company will be a refreshing and attractive quality. And don’t worry about scaring off a candidate who is afraid of a blemish. You don’t want to hire someone who wants to work for a perfect company with no opportunities to contribute to the solutions of the real problems that every company has.
5. Follow up and answer a candidates questions after the interview process is complete and make a decision as quickly as possible. If you will have some delays before you can make a decision, keep the lines of communication open and keep the candidate up to date. This kind of follow through is often overlooked and companies often take for granted that the candidate will sit still and wait. They won’t. To keep a fish on a hook, as they say, you have to work the line. Let it go slack, and you’ll lose.

Keeping Top Talent
Once you have hired a key employee, make an opposites list from the Forbes article and work toward eliminating the reasons that top talent walks out the door. Of the ten, here are my top picks recast as things you should do to keep top talent on your team:

1. Give your employees an opportunity to have a voice in key policy and process decisions. Listen to your people with an open mind, prepared to change your mind if you have overlooked something. Your top talent will often have better ideas than you may think.
2. Take the time to provide regular feedback to your employees. Annual reviews are great, but follow up with periodic reviews of goals, professional development, projects and opportunities for improvement. And always find a way to share positive feedback. When you acknowledge achievements and performance, publicly and privately, you’ll get even more of the same.
3. Make sure that your team members know that you care about their professional career development. The small amount of time you invest in helping your team map their future success will yield returns in happy, dedicated employees much greater even than the recent gains in the gold market.
4. Steer a steady ship that can make tactical adjustments in course but is on a solid strategic heading. If you run into stormy waters, keep faith with your employees and stay on course. If you need to make strategic course changes, involve your top talent in that decision making. Getting on a boat headed for Hawaii and finding out that the captain has decided to go to Alaska instead without even talking to you can be more than demoralizing.
5. Build teams of people who can work well together, who are talented and skilled and willing to pull their own weight and then some. Passionate people will help to bring out the best in team members who are having a bad day, but it is impossible to fix a team member who fundamentally lacks the requisite skills and desire to acquire them.
6. Be open minded and tolerant of opposing points of view. If you do not invite honest discussion with your team at appropriate times, you will lose your top talent and end up with a team that affirms any decision you make, even those that will send you off a cliff that you did not have the foresight to recognize.
7. You can teach management skills to a leader. But teaching leadership skills to a manager is not so easy. Look for leaders who can motivate and rally teams. You can hire a clerk or accountant to take care of the bean counting. But you may not recover from having a leaderless team and the resultant chaos and confusion and serial loss of top talent that will result. Do not be afraid to amputate and stop the bleeding. Keeping a failed manager long beyond the point of recognizing the problem to avoid the pain of change is an ominous sign to your top talent that you lack the leadership required to steer the ship successfully to port and they will abandon ship at the first reasonable moment.

If you’re making New Year’s resolutions with respect to your company, I urge you to review these lists, and the plethora of others available on the web from sources far more authoritative than me. Take positive action to attract and keep your top talent. And if you find yourself looking for a company that exhibits these desirable qualities, keep up your search. They are out there. And while no company is perfect, there are certainly some that far and away exceed others. So whatever you do, don’t give up hope of a better day.

Dennis Ritchie, the Father of C, passed away a few days ago. A friend asked me today, “Would we have had a Steve Jobs without first having a Dennis Ritchie?” He made a great point. The most common programming language for the Apple platform today is Objective-C. Mr. Ritchie was not an attention hound it seems. I doubt more than 1% of the people who know who Steve Jobs is would know who Dennis Ritchie is, and yet, we in this business of programming owe him a great debt of gratitude.

I know there are C detractors, but the ubiquity of C and all it’s descendants cannot be denied. Andrew Binstock, in his column today on Dr. Dobbs, quoted Mr. Ritchie as having said:

“C is quirky, flawed, and an enormous success. [And UNIX] is very simple, it just needs a genius to understand its simplicity.” ~Dennis Ritchie

Oh yeah, and I forgot to mention he was also deeply involved in developing UNIX. And how many derivatives of UNIX are there? And how many other operating systems at their core are so like UNIX as to make the grand old operating system the true grandfather or at least uncle of every seriously utilized operating system in the world?

I will end by borrowing Mr. Binstock’s conclusion:

“Ritchie saw in language what others could not see, in operating system what others had not built, and in the world around him what others did not realize. His insight and the elegance of his work will be missed by all programmers, even in future generations who, as he would want it, might know nothing of him.” ~Andrew Binstock

Thanks, Dennis Ritchie. Thanks for C. And thanks for UNIX.

And whatever you do, don’t miss this farewell from MuppetLabs. Thanks for sharing it, Dave.

I’m gradually catching up with presentations from last month’s BUILD conference on Channel 9. Today I ran into a blog post by Samuel Jack in the UK on the topic of what’s new in C# 5.0. I recommend you read his blog, but more strongly recommend you watch Anders Hejlberg’s presentation on Channel 9 about C# 5.0 and VB 11.0.

Among my favorite goodies are the async and await keywords. For anyone who has put off learning how to write asynchronous application behavior because it is just too hard to understand, you are in luck. Wait a few more months, perhaps a year, and you can learn just a few easy concepts about how to use async and await keywords in your code and you will be an asynchronous coding wizard.

Exciting times!

Recently I came across an interesting list of top ten time wasters at work. I jotted them down but have lost the source, so I apologize for not providing the link. Here’s their list:

1. Instant Messaging
2. Over-Reliance on Email
3. Meandering Meetings
4. Short Gaps Between Meetings
5. Reacting to Interruptions
6. Ineffective Multi-Tasking
7. Disorganized Workspace
8. Personal Communication
9. Web Surfing "Breaks"
10. Cigarette/Coffee Breaks

It’s a decent list that one might find on many top ten sites, I’m sure. But it’s not terribly accurate. You see, the biggest time waster in the enterprise is the Meaningless, Meandering Meeting Machine. So here’s my revised list:

1. Thinking about meetings.
2. Planning meetings.
3. Doodling in meetings.
4. Talking about meetings.
5. Scheduling and rescheduling meetings.
6. Meetings.
7. Follow-up meetings.
8. Looking or asking for minutes from meetings.
9. Assuming people will do what was agreed to in meetings.
10. Making lists about meetings.

I have seen good, productive employees become consumed by the Meaningless Meetings Machine. It is an endless recursive function leading to enterprise stack overflow. Sometimes executives are lost for months in the Machine and when employees smart enough or lucky enough to stay away from the Machine are asked if they have seen Mr. Soandso, they say, No, and hurriedly move on lest they too be sucked into the Machine.

In April of this year, an executive of another company told me in a telephone conversation, "Everybody lies. You just have to get used to it."

I was stunned by the statement and have given it a lot of thought since then. It reminded me of a scene from Babylon 5 that went something like this:

Garibaldi: Everybody lies.
Edgars: That's a very sad view of the universe, Mr. Garibaldi.
Garibaldi: Yeah, well, it's the only one I got. And it works for me.
Edgars: The truth will be revealed in a couple of days. How many people can say that?
Garibaldi: I don't know. But I think the last guy got thirty pieces of silver for the same job.

Dishonesty in this technological age has even produced its own vocabulary, specifically the verb "to blag." The third definition of "blag" in the Urban Dictionary:

To convince another person that all the stuff you just made up is in fact true and worthy. Example: "Caught in a tight spot, Harry blagged his way through the conversation and somehow got the job."

I do not wish to accept the dim view that everybody lies. And I certainly do not wish to get used to it, in any way shape or form. And yet there is growing evidence both anecdotally in my own professional career and globally that the enterprise often creates a dishonest culture. Author Brian Amble in Management Issues filed a piece in 2005 entitled Corporate Culture Encourages Lying. The author mentions "blagging" and makes these three very interesting points:

"The rot starts at the top, revealing a surprisingly ambivalent attitude amongst...bosses towards the honesty – or otherwise - of their staff."

"The vast majority of company directors and senior managers believe it is wrong for their employees to lie to them. But almost half are comfortable with those same employees telling untruths on their behalf to their customers – with female bosses even more tolerant of this sort of behavior than their male colleagues."

"[Microsoft] encourages decision-making [using a] technology-based process that creates permanent digital records and maintains the integrity of the information on which those decisions are based."

In my experience blagging is most especially prevalent in the world of software development where management clings to the notion, and consultants sell the latest process magic to reaffirm the assumption, that building software is like building a house, sufficiently predictable and repeatable so as to accurately establish a firm budget, timeline and resource commitment before ground is broken. Software artisans then find themselves in the very uncomfortable position of feeling pressured to lie to their patron bosses who clearly do not wish to know that building software is often as much an unpredictable art as it is in any way a predictable science.

Software craftsmen who boldly stand their ground and declare, "I don't know how long it will take to build that," are more often attacked and labeled malcontent and misfit, shunned by managers who insist that they can bend reality to their will while they ignore what their experts have told them. And lower management who know better are caught in the ultimate catch 22. They may believe their lead developers or software architects when they say, "we cannot deliver all these features on that date," but they cannot report that fact to their own managers or customers, so they choose to lie in order to protect and even advance their own career knowing that if the implementation team fails, they may avoid accountability by throwing the developers under the bus, asserting the implementation team is incompetent and ought to be replaced.

Given the impossible circumstances in which software craftsmen find themselves, they often resort to lying to themselves and their bosses asserting that they can produce some piece of software, despite the general lack of specific requirements and understanding of the problem domain or the target users, within the time budget and resource constraints imposed by management. And then in order to avoid being exposed as just another blagger, the software artisan (or collectively the team) works impossible hours, makes imprudent quality compromises and desperately seeks for external circumstances which can be blamed for delays. Knowing that such responsibility diverting opportunities always arise, the software artisan begins to accept and even embrace the culture of lies produced by her circumstances until she does not even recognize the truth.

I know that this scenario is not universal. There are organizations who take great steps, incorporating technology and constant vigilance, to avoid the traps of dishonesty. These organizations are led by honest people who genuinely listen to their people and avoid the trap of boxing their software craftsmen into a set of assumptions that are untenable at best and downright foolish at worst. Dr. Rhonne Sanderson said it best in an article by Marcia A. Reed-Woodard entitled Don't lie to me: dishonesty can ruin professional and personal relationships:

"Although lying provides an easy out in the short-term, it comes with serious repercussions," says Dr Rhonne Sanderson, a Dallas--Fort Worth area licensed psychotherapist. He maintains that the fallout from lying can hurt others, ruin relationships, as well as rob the liar of integrity, credibility, confidence, and self-esteem. "Lying only exacerbates the real problem."

If we let honesty govern our dealings with our fellow man, we will all be the better for it. We do not need to sacrifice civility for honesty, nor should we mistake an honest disagreement for disrespect or insubordination, for when we do, we encourage others to be dishonest through their silence.

We can boldly speak the truth and expect others to do so. We can hold ourselves and others to account. We need not settle for the notion that everybody lies. And we certainly do not need to get used to it. We can and ought to do and be better.

A certain angel investor chose three companies in which to invest a relatively large sum. In the first, he invested $10 million. In the second, he invested $5 million. And in the third, he invested $1 million. A year later, the first had doubled in value because it had boldly used the capital to execute on its business plan. The second company had also doubled in size because they had taken the investment and worked very hard to grow their business. The third company had run into some problems and was afraid of losing their capital, so they did nothing and had nothing to show for it. The angel investor liquidated his interest in the third company and those people are now looking for work.

Yes, I’ve borrowed the plot for that story from someone much wiser than me. But it applies in today’s world of technology and software development as much as it applies to the context for which it was originally told. Fear paralyzes us into inaction or into making unwise choices which almost always result in the corruption of otherwise sound business processes and just as often leads to complete and utter failure.

One of the greatest fears in software development that corrupts process and assures failure is the fear to tell the client or customer no. In the world of software development, especially in internal enterprise software development, the fear of saying no can be so paralyzing that we often place impossible burdens on teams already pushed to their limits. The fear of saying no can lead us to short circuit our process, skip critical steps and gloss over real analysis and careful design. The fear of saying no can lead to general discord when a team member objects and the manager angrily brushes her off, dismissing her concerns as irrelevant or inconsequential. This fear leads to chaos and assured failure. Failure to deliver on time. Failure to communicate and manage realistic client expectations. Failure to establish credibility and confidence with the client and the organization. Failure to keep and foster a well organized, happy and productive team.

So how can one overcome this fear? You just jump. How does the diver overcome his fear of heights to jump from a platform so high the first time? He just jumps. How does a skydiver overcome her fear of falling to her death from an airplane? She just leaps or is pushed. And then training and preparation take over and fear is overcome. You may never completely overcome the fear of saying no. But if you jump, take a leap of faith, just do it, you’ll find that you have not died and that you will have an easier time doing it the next time.

When we overcome our fear and take a leap of faith, we can accomplish great things. Let us work like the first two companies in our story and succeed.

I enjoy continually learning from Robert Martin (Uncle Bob). Sometimes I disagree with him but usually only until I’ve thoroughly processed what he is trying to teach me. In his latest missive on 8thlight.com, Uncle Bob writes a stunningly cogent brief called Screaming Architecture in which he makes a critical point: software architecture is all about the use cases of a system and NOT the framework.

“Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.”

Focus on the use cases and perhaps even group them into logical hierarchies with tidy “40,000 foot level” epochs that describe the thing you are building. Is it a customer relationship management system? The first thing we should notice in an architecture, whether document or code, is that this is a CRM system. Presentation, delivery, storage and communication frameworks are all secondary, just plumbing, not the architecture.

“A good software architecture allows decisions about frameworks, databases, web-servers, and other environmental issues and tools, to be deferred and delayed.”

I’m not completely at this point in my journey toward architectural perfection but I recognize the need to strive for this idea of producing architectures that are designed to solve the problems of the users first rather than designed fit within the strictures of a framework while addressing the use cases after the fact.

I recommend you read the full article. Take Uncle Bob’s advice, as I intend to do, and focus more strongly on architecture for your use cases on your next project. Use frameworks carefully and work to keep your business code independent of your frameworks and thus imminently more testable. And don’t forget your tests.

I’ve recently been interested in the subject of respect and the question of whether respect is given or earned. My conclusion is that respect is given most often when it is earned and certainly most easily when that is so. In contemplating and researching this subject, I ran across a post by Bret Simmons that I liked very much called 10 Ways to Earn Respect as a Leader in the Workplace.

I recommend you read the full article but I’ll share a few of my favorites here along with some personal thoughts about each one.

Get to know your co-workers and their families.
This is the author’s first point and I think most important one. It is very hard to give respect to someone who has no empathy and does not appear to be genuinely interested in you and your personal circumstances. A little bit of real care can earn a lot of respect.

Communicate clearly and regularly.
If one does not hear from or speak with his manager on a regular basis, it is impossible for the first point to occur. And if a person is left in the dark with respect to what is happening within the organization, an atmosphere of fear and a feeling of neglect can result in poor attitudes and even overt disrespect.

Make generous use of self-deprecating humor.
When I work with someone who refrains from making deprecating remarks about others but has the self confidence to take a jab at himself from time to time in order to put others at ease, I’m more likely to feel comfortable working with that person and will certainly have more respect for him.

Admit when you screw up.
Nothing can destroy the respect you have earned more rapidly than dodging responsibility for your own mistakes. Nothing can more irreversibly damage your own reputation more powerfully than when you throw a subordinate or coworker under the bus rather than owning up and facing the music. At the same time, the opposite is true. If I have a boss who takes responsibility for mistakes made and asks the team for their support as she takes corrective action, I will have just that much more respect for that person.

Stand behind your staff during times of difficulty.
When mistakes are made by subordinates or coworkers, stand by them. Don’t abandon them in an attempt to save yourself. Chances are you will all survive but you will have lost their respect forever. The author writes, “If you can’t stand behind one of your team members, then you don’t belong in management and you’re certainly not a leader.”

I remember listening to this wise counsel three years ago from Elder Joseph B. Wirthlin Of the Quorum of the Twelve Apostles. Today my mother reminded me of it and I enjoyed reading it again. If you have ever faced tough times or felt like you were on the losing end of a game, in sport, in work, in life, I hope this article will pick you up.

I would like to highlight one of the points Elder Wirthlin makes, perhaps my favorite:

Learn to laugh – When things go wrong, we can choose to be angry or sad or depressed, but if we choose to laugh, we can get through the present difficulty and more easily find a solution.

“The next time you’re tempted to groan, you might try to laugh instead. It will extend your life and make the lives of all those around you more enjoyable.”

When the stresses of work or a commute or a family crisis threaten to bring you down, laugh. It truly is the best medicine!

I spend perhaps six hours a day, five days a week, fifty weeks a year hitting the keys. At my slow average typing speed of 30 words per minute (I can type faster but I’m not constantly hitting the keys, so I’m guessing here) and assuming I spend thirty years of my life doing this, my total keystrokes (assuming an average of 6 keystrokes per word) will be:

60 minutes * 6 hours * 5 days * 50 weeks * 30 years * 30 words * 6 keystrokes = 16,200,000 keystrokes

Percentage of my work output firing off an ill conceived email providing advice to someone who does not care or want the advice and will certainly not waste time reading the missive: 0.01%

Today I wasted 0.01% of my available productivity.

I’ve already consumed nearly 50% of my available keystrokes, so I’m posting this to remind myself to conserve my energy and use what remains of my personal utility more wisely.

Important note to self. Do not waste time writing perfectly good advice and sending it to someone who could not care less about your opinion. Instead, read a good book. Write a new blog post. Refactor some old code. Or just watch the leaves in the trees dance in the wind. This would be a more valuable use of that time. Time that cannot ever be recaptured.

I like many aspects of my job but one stands out above all others: helping other developers. Nothing gives me as much satisfaction as hooking up the mental chains and pulling a fellow developer out of the code mud in which she or he is stuck.

I grew up on a small farm where there was never any lack for work to do, much of which was tedious and boring. But it was always exciting to get a call from a neighbor asking us to come pull them out of the mud or jump start a car or rescue an animal from some odd predicament. It never took much time, but the simple gratitude of the person helped was the best compensation I’d ever known as a child.

Now my tractor is my brain and my software tools and the chains are made of thousands of hours of experience forging one experience into another and storing these up, mostly for my own work, but also for those enjoyable moments when I take a call from a colleague who is just stuck and needs a little guidance.

My tractor and chain is not better than anyone else’s really. But sometimes I’m in the right place at the right time to help another developer and this aspect of my job is my favorite. Spinning up a GotoMeeting session and helping another developer find and solve a problem may sound dull and boring to some, but it gives me a boost.

Sometimes my colleagues are reluctant to call. (I work remotely.) Perhaps this is because they don’t want to waste my time or because they feel the need to solve the problem on their own. That’s okay. It’s good to solve problems on your own but I do appreciate the opportunity to help when I can.

And that is one of the main reasons I get up in the morning and make the 30 second commute to my basement office. Today, I might get to hook up the chains to the tractor and pull a friend or a neighbor out of the mud.

Hook up your chains to your tractor and become a software development mentor.

Someone once said, “By small and simple things are great things brought to pass.” The context was certainly not enterprise software development but I have come to believe that these words are profound in this context as well.

Every enterprise, medium and large, is challenged with complexity. Their systems and businesses are complex. Their politics and personnel and departments are complex. Their business models and markets and product lines are complex.

And their software is complex. But why?

Because we make it complex. We accept the notion that one application must accomplish all the wants and wishes of the management for whom we work, either because we are afraid to say, “This is a bad idea,” or because we are arrogant enough to think we’re up to the challenge. So we create large teams and build complex, confusing and unmanageable software that eventually fulfills those wants and wishes, sometimes years later—that is, if the project is not cancelled because the same management team loses patience and/or budget to see it through.

Some companies have made a very large business from selling such very large and complex software. They sell it for a very large “enterprise class” price to a business who wants all those nice shiny features but doesn’t want to take the risk of building it for themselves. And then they buy the very large enterprise software system and find that they must spend the next six to twenty months configuring and customizing the software or changing their own business processes and rules to fit the strictures of the software they have purchased.

The most successful enterprise projects I’ve worked on have all shared certain qualities. These projects have produced workable, usable and nearly trouble-free service all because they shared these qualities. The are:

• A small team consisting of:
• A senior lead developer or architect
• Two mid-senior level developers
• A project manager (part time)
• And a strong product owner (part time)
• A short but intense requirements gathering and design period with earnest customer involvement.
• Regular interaction with product owner with a demo of the software every week.
• Strong communication and coordination by the project manager, assuring the team and the customer understands all aspects of project status and progress.

The challenge in the enterprise is to find the will and means to take the more successful approach of “small and simple.”

You may say, “Well, that’s all fine and good in some perfect world, but we have real, hard and complex problems to solve with our software.” And that may be true. Software, no matter how good, cannot remove the complexity from the enterprise. But there is, in my opinion, no reason that software should add to it.

The real genius of any enterprise software architect, if she has any genius at all, is to find a way to break down complex business processes and systems into singular application parts that can be built by small, agile teams like I’ve described, and where necessary, to carefully define and control the service and API boundaries between them.

Must a single web application provide every user with every function and feature they might need? No. But we often try for that nirvana and we often fail or take so long to deliver that delivery does not feel like success.

Must a single database contain all the data that the enterprise will need to perform a certain business function or fulfill a specific book of business? No. But we often work toward that goal, ending up with a database that is so complex and so flawed that we cannot hope to maintain or understand it without continuous and never ending vigilance.

When your project complexity grows, your team grows, your communication challenges grow and your requirements become unwieldy and unknowable. When you take on the complex all in one with an army, you cannot sufficiently focus your energy and your strength and collectively you will accomplish less and less with each addition to your team until your project is awash is cost and time overruns, the entire team collectively marching to delivery or cancellation. And in the end either outcome, delivery or cancellation, feels the same.

By small and simple things, great enterprise software can be brought to pass. Sooner rather than later. Delivering solid, workable, maintainable, supportable solutions. Put one small thing together with another, win the war on complexity and provide real value to your management team. Do this again and again and you’ll have a team that will never want another job because they will have become all too familiar with real success.

I’ve had a series of ongoing discussions with a friend who is also a senior software architect. In recent months he’s become quite dissatisfied with his manager specifically and employer generally. He has put his resume out on the typical job search sites, Dice, Monster, TheLadders, LinkedIn and others, and has been sorely disappointed with the result. Technical recruiters seem to be, with rare exceptions, a sorry lot of would-be telemarketers rejected for lack of integrity by the local call-center-for-hire.

On a daily basis this friend of mine receives emails and calls with a hot job listing that do not generally match his skills or experience like the one that he forwarded to me today, not because he might really be a match but in hopes of sparking a conversation that goes something like this:

• Recruiter: “I know you may not be a good fit for this job, but do you know anyone who is?”
• Candidate: “No. I do not know anyone with this skill set and experience level interested in a 6 month contract.”
• Recruiter: “Okay. I’d like to keep in touch with you and I will definitely call you if something comes through that is a better match for what you’re looking for.”
• Candidate: “Okay, sure. Thanks for the call.”

My friend reports that he has at least three of those conversations per week and at least two or three such emails as the one below per day. I’ve changed the company names and the place to avoid the chance of embarrassing any of them, especially since one or two of them is a household brand name.

Hello,

I am Recruiter with XYZConsulting (formerly ABCConsulting), a dedicated QRS contractor sourcing service, managed by TenCharms. We recruit solely for QRS Contract Positions. Should you accept a contract position, it will be through our preferred partner TenCharms, an independent vendor chosen to manage this program for QRS.

I saw your resume on a job board. I am currently recruiting .net Consultant for a 12 months contract project with QRS – Chicago, IL.

Email me a copy of WORD formatted resume, along with these details:

• Best time & number to speak to you:
• Location:
• Visa Status:
• How soon you can start:
• Work mode, W2, C2C (if self-incorporated):
• Expectations on Compensation:

Position’s name: .net Consultant

Assignment period: 12 months
Location: Chicago, IL

Required skills
Primary Skills: asp.net, vb.net, Oracle / SQL Server, SQL. Secondary Skills: C#.net, MS Access / VBA

As this is an urgent requirement, kindly respond to it at earliest possible.

Best Regards,
Bad Excuse (name changed to protect the guilty)

Recruiter | XYZConsulting (formerly ABCConsulting)
A TenCharms Solution
Dedicated QRS Contractor Sourcing Services

My friend has shown me many other emails that are far worse than this one. Many of them are poorly written, lacking proper grammar and teeming with spelling errors, yet they claim to represent well known companies. I wonder if these companies for whom these recruiters work ever bother to review the practices and general quality of the communications of their agents. Somehow I doubt it.

In some of the emails my friend has forwarded to me, it becomes clear that the recruiting company has employed some shoddy keyword matching algorithm to select from a list of candidates who have put their resumes out into the swamp of job sites (see above mentioned sites). In some of these I have been able to identify one or two specific keywords that match my friend’s resume. I should know. I helped him write it.

Sometimes the keyword match is even close, such as, “architect” or “jQuery.” But since my friend is a .NET architect and the job is for a J2EE architect who also knows jQuery and PHP and Oracle while my friend does not mention Oracle or PHP on his resume at all, it is clear that the recruiter’s matching algorithm, whether it is their own or provided by one of the job sites, is severely lacking in even the most basic intelligence.

Either that or the recruiter is far more interested in spamming the candidate with a job posting that is clearly not a fit in hopes that the candidate will do the job of the recruiter for him or her or it.

To all such recruiters, please for the love of Pete, what’s wrong with you? Stop wasting my friend’s time!

I have worked in several development teams that have a Scrum-like development process where the team has adapted Scrum to their own team dynamics and organizational needs. I was intrigued by a recent MSDN article called Visual Studio ALM Rangers—Reflections on Virtual Teams that formalizes one of these this Scrum-but-not-Scrum processes and calls it Ruck. Here is the authors’ loose definition:

“To ensure that we don’t confuse anyone in terms of the methodologies or annoy process zealots, we provisionally chose to call our customized process ‘Ruck,’ which, in the rugby world, means ‘loose scrum.’”

The article authors share their experience in Microsoft’s ALM Rangers team and “provide guidance for working with teams in less-than-ideal distributed and virtual environments.” I found this introduction compelling and I wanted to try to restate their approach here with a few of my own thoughts mixed in.

The ALM Rangers’ Ruck process is very specific to their needs and team: a highly distributed team and a high degree of variability in team member availability where team members have multiple professional obligations that take higher priority than their work on the team. This is a very challenging situation for a team trying to be Scrum-like and may be closer to many popular open source projects with multiple contributors from around the world, with one very important exception: a fixed ship date.

I’m not advocating that any specific team adopt the ALM Rangers’ Ruck, but the choices and approach taken by this team could be very valuable to other teams faced with creating their own Ruck because they cannot, for whatever reason, get close enough to Scrum to really call their process Scrum.

One of the most important points I found the authors making had to do with adhering to the agile principle of self-organizing teams. They found that their “belief in letting developers choose work from areas in which they have interest” required that they allow teams to self-organize around these areas of interest rather than specific geographies or time zones.

One of the most difficult challenges facing enterprise software development projects is team size and how to break up larger projects into smaller chunks that can be addressed by smaller, more agile teams. The authors observe:

“We’ve learned that smaller projects and smaller team sizes enable better execution, proper cadence and deeper team member commitment. Also, it seems it’s more difficult for someone to abandon a small team than a larger team.”

Another interesting area the authors cover is that of project artifacts used to manage and break down the project into actionable tasks. The particular names of these seem less important than the fact that they are well defined and communicated and used consistently within their Ruck. In creating your own Ruck process, do not skip this important element.

Roles are also well defined. Knowing what position you play on the team at any one given moment can eliminate the need for over-the-shoulder management because each team member knows what their responsibility is. The task of the manager becomes one of coach rather than hall monitor, communicating these roles and responsibilities to team members rather than asking the question, “so what are you working on today?”

One more critical area to define is meetings. Don’s skimp on structuring meetings to achieve what you need to achieve without wasting too much time. As my brother tells me, “It takes a really good meeting to beat no meeting at all.”

And finally, I want to share one more brief excerpt from the authors. Their top recommendations:

“There are many recommendations, skills and practices that will help you improve the virtual team environment, the collaboration and effectiveness of each team member, and the quality of the deliverables. For us, the seven top recommendations include:

1. Clearly define and foster a team identity and vision.
2. Clearly define the process, such as the Ruck process.
3. Clearly define the communication guidelines and protocols.
4. Clearly define milestones, share status and celebrate the deliverables.
5. Implement an ALM infrastructure that allows the team to collaborate effectively, such as TFS and associated technology.
6. Promote visibility and complete transparency on a regular cadence.
7. Choose your teams wisely, asking members to volunteer and promoting passionate and get-it-done individuals.”

I normally use this blog to write of technology but today is a justifiable exception. Today I am reminded of and enjoyed reading again the words of a Prophet of God, Gordon B. Hinckley, spoken in a conference just a few short weeks after the fateful day ten years ago. I invite you to read his entire address, but here are a few excerpts:

You are acutely aware of the events of September 11, less than a month ago. Out of that vicious and ugly attack we are plunged into a state of war. It is the first war of the 21st century... But this was not an attack on the United States alone. It was an attack on men and nations of goodwill everywhere.
...
Religion offers no shield for wickedness, for evil, for those kinds of things. The God in whom I believe does not foster this kind of action. He is a God of mercy. He is a God of love. He is a God of peace and reassurance, and I look to Him in times such as this as a comfort and a source of strength.
...
Now, all of us know that war, contention, hatred, suffering of the worst kind are not new. The conflict we see today is but another expression of the conflict that began with the War in Heaven. I quote from the book of Revelation:

“And there was war in heaven: Michael and his angels fought against the dragon; and the dragon fought and his angels,

“And prevailed not; neither was their place found any more in heaven.

“And the great dragon was cast out, that old serpent, called the Devil, and Satan, which deceiveth the whole world: he was cast out into the earth, and his angels were cast out with him." KJV, Rev. 12:7-9

From the day of Cain to the present, the adversary has been the great mastermind of the terrible conflicts that have brought so much suffering. Treachery and terrorism began with him. And they will continue until the Son of God returns to rule and reign with peace and righteousness among the sons and daughters of God.
...
Are these perilous times? They are. But there is no need to fear. We can have peace in our hearts and peace in our homes. We can be an influence for good in this world, every one of us.

May the God of heaven, the Almighty, bless us, help us, as we walk our various ways in the uncertain days that lie ahead. May we look to Him with unfailing faith. May we worthily place our reliance on His Beloved Son who is our great Redeemer, whether it be in life or in death, is my prayer in His holy name, even the name of Jesus Christ, amen.

Update: Please read commentary posted by Thomas S. Monson, a living Prophet of God, in the Washington Post.

As I sit here nursing a head plagued with a migraine, I read with great interest Eric Sink’s latest in my RSS reader about his experiences learning Scrum, a paper submitted for the proceedings of Agile 2011. Here’s my favorite part:

“I have come to think of our daily standup as being similar to a security guard at a bank. Most security guards stand around for their entire career without ever firing their weapon. It's probably a boring job. But the consistent presence of that security guard probably prevents some big problems from ever happening. Our daily standup is the same way.  Nothing exciting ever really happens. But we can confidently assume that many big problems have been avoided because we regularly take the time to get synced up.

“The culture of Scrum teams seems to be built on working together in shared spaces. In contrast, our company has always placed a high value on each person having a private office.

“We are aware that there are tradeoffs here. A private office gives each person a quiet place to work, but it also creates the opportunity for people to get isolated. So even as we provide private offices, we create ways to drag people out of them, including soda in the kitchen, lunch together on Wednesdays, a pool table, and a video game room.”

For this I would consider relocation to Illinois. And I always tell recruiters I’m not interested in relocating.

Occasionally other developers with whom I work will comment on my productivity. For example a couple of weeks ago, after working hard one day and delivering an urgently needed service to the team the next morning, one developer said in standup, "You're an animal. You wrote that in one day and it would have taken me two weeks to do that." I’m a little embarrassed by such comments and have often thought about what makes me or any programmer productive, so today I enjoyed reading parts of Neal Ford's book The Productive Programmer and wanted to share some thoughts on programmer productivity.

I loved the forward by David Bock of CodeSherpas. He writes, "The individual productivity of programmers varies widely in our industry. What most of us might be able to get done in a week, some are able to get done in a day. Why is that? The short answer concerns mastery of the tools developers have at their disposal. The long answer is about the real awareness of the tools' capabilities and mastery of the thought process for using them. The truth lies somewhere between a methodology and a philosophy, and that is what Neal captures in this book."

Ford suggests there are four productivity principles for programmers.

1. Acceleration: speeding things up. Keyboard shortcuts, searching and navigation.
2. Focus: eliminating distractions and clutter, both physical and mental.
3. Automation: getting your computer to do more. Put your computer to work.
4. Canonicality: doing things once in one place. Also known as DRY or Don't Repeat Yourself.

These are all good and important. For me the most important item in Ford's list is number two: focus. And I would add one more: conditioning. Focus and conditioning are the two most important keys to successfully improving your programming productivity.

Programming Productivity Key #1 – Focus

Start by eliminating mental and physical distractions. Remove the clutter from your mind and your desk, but most importantly, eliminate the distractions caused by environmental disruption. Find or create a quiet place where you can focus on the task at hand, where you can put your entire mental energy into what you are doing. Distractions are a HUGE productivity destroyer.

Cubicles are of the Devil. They may be great for a sales team or reporters who thrive on eavesdropping, but chit chat does not get code written. Cubicles foster incomplete and sporadic communication that becomes a crutch for broken requirements and shoddy analysis resulting in an unsearchable and unsellable body of knowledge persisted only in the fragile collective of a distributed and disconnected human neural network that often cannot survive the loss of one or two key nodes.

Ford suggests instituting "quiet time" where, for example, there are no meetings or email or talk during two two-hour periods each day. He claims to have tried this in one of the consulting offices where he worked and the organization found that they got more done in those four hours than was getting done in the entire day before implementing the "quiet time." This is not surprising to me at all. Ford writes, "It is tragic that office environments so hamper productivity that employees have to game the system to get work done."

While I have the luxury of working from a home office at the moment, I have worked in a number of cubicle environments in the past and probably will in the future. The most common technique I see other developers using to create their own "quiet time" is the use of a very expensive pair of noise canceling headphones piping in whatever tunes or white noise that developer finds most conductive to focusing on the task at hand. Do whatever you have to do to achieve focus.
 

Programming Productivity Key #2 – Conditioning

To play at the top of your game, you have to condition. You have to practice. You have to study. You have to prepare your body but most importantly your mind to execute. And you have to condition your attitude. You have to be excited to write code. You have to get a thrill out of making it work and work well. You have to condition your mind to expect excellence and then work to achieve that.

In conditioning, there are mechanics you must learn. Spend time studying and using your IDE's keyboard shortcuts. Regularly study and practice using the base class libraries of your platform so you don't end up wasting time writing code that a solid community or well heeled development team has already written and tested heavily for you.

More importantly, spend time reading about and learning new techniques and technologies from open source projects to gather at least a passing understanding of the problem they solve and how you might use them even if you choose not to do so. Pay attention to the patterns, the naming and organizational patterns, the logical patterns and the problem solving patterns that you find in these projects. Even if you do not use them, you will be storing up mental muscle memory that will serve you well when you need a way to solve a new problem in your own projects.

Most importantly, learn from your own work. Repeat your successes, taking patterns from your past and improving on them. Avoid your failures, being honest with yourself about what did not work in your last project and finding ways to avoid or even invert the mistakes of the past, turning them into strong successes.

Conditioning is not about solving a problem for a specific project in which you're working now. It's about preparing your mind to be at its most productive when faced with programming problems you've never seen before. It's about creating mental muscle memory that will kick into overdrive as you solve the problems you have already faced, the code spilling out of your brain through your fingers and into the keyboard.

Conclusion
No matter how fast or slow you are as a programmer, you can improve. If you improve your focus and put your body and mind through regular conditioning, you will improve. And as you improve, you'll get noticed. And as you get noticed, you'll get rewarded.

Microsoft announced recently that Visual Studio LightSwitch 2011 will be released on July 26. I’ve been watching the development of this product with keen interest for the last year or so. I’m looking forward to evaluating it more in-depth soon.

Building common line-of-business (LOB) applications in today’s enterprise development stacks can be too complex and too costly for today’s tight budgets. For this reason alone there are “literally millions” (exaggeration license: 02389-872.159-034) of LOB applications being created by non-programmer Office users. These “applications” most often get pushed around in Excel via Exchange. Many live in a hastily created Access database and shared clumsily and un-securely on a workgroup file server.

Still others are somewhat more sophisticated and are hosted on products such as QuickBase from Intuit. This latter category resolves many of the problems inherent in the emailed Excel spreadsheet and the Access fileshare such as security, reliability, common user interface, ease of use, etc. There are many more specialized web-based SaaS offerings that solve specific business problems. One notable vendor who led the way in this area is 37 signals.

But these solutions are not always enough to meet the needs of the business. There is a gap between these “entry-level” (ELOB) applications and what I will call primary line-of-business (PLOB) applications. The PLOB is a custom developed, sophisticated enterprise application with complex business rules, sometimes even more complex user interfaces, and far more complex data and integration requirements, upon which the business relies for its core service offering or mission critical systems.

Somewhere between ELOB and PLOB there has to be a middle ground. Let’s call it the mid-line-of-business (MLOB) application (FLA creator license: FOLK-LANG-MAKE-UPPR-WXYZ). There are plenty of “app generator” and scaffolding tools that claim to live in the MLOB space. I’ve never been too impressed with them. They always seem to lose their way in convention, diverging from business requirements too greatly to meet business needs.

So I am hopeful that LightSwitch will fill the MLOB gap. We’ll see. Time will tell. In any case, it should at least be fun to find out.

How many games will an NFL team win if the coaching staff and the owners remain in the locker room during practices and games, coming out only at half time and between quarters to ask the team members what they can do to win the game?

ESPN’s Worst NFL teams of all time include:

#1. 1976 Buccaneers (0-14)
It was their season debut. They were shut out five times and averaged fewer than nine points per game. Defensive lineman Pat Toomay said, “The coach stopped talking to us after the third game. During the week, he wanted nothing to do with us.”

… (You can read more on the page linked above. I’ve included snippets here of the two that I felt illustrated my point.) …

#9. 2001 Carolina Panthers (1-15)
”The energy has been sucked out of our organization and our fan base,” said owner Jerry Richardson, after firing head coach George Seifert at the end of the year.

Great players cannot win consistently without great coaches. The same is true of software development teams, or any other type of team for that matter. If the coaches remain in the locker room, the team, being paid professionals, will still play, and they might even score, and with ideal conditions, they might even deliver a win or two, but a losing season can be guaranteed when the coaches and owners can’t be bothered to be a part of the game.

On the other hand, we have great examples such as Vince Lombardi who went to work for the Packers and turned a 1-10-1 in 1958 team into one of the greatest teams in the game and with five NFL championships before he left nine seasons later. He was in the game. He was a motivational leader. He was a great coach.

Or how about Tom Landry and his goofy hat who coached the Cowboys for 28 years and had a 20 year winning season streak. He was a great coach.

This list of winning coaches is long. Only the losing players on a losing team remember their losing coaches beyond the losing season. Winning coaches are remembered and revered long after they’ve left the field.

And how many games do you think those winning coaches missed?

Who was your greatest coach? And why? I want to hear from you.

In a press release from Redmond today, we get a little preview of what is to come with Windows 8 and it is HTML 5 and JavaScript.

I have mixed emotions about all of this. Some may say that it’s like putting lipstick on a pig, but in fact I don’t think Windows 7 is a pig at all. It beats any other desktop OS, bar none, and no, I don’t want to hear it from the Mac crowd (see my previous post). For me, it feels like putting an enhanced Windows Phone 7 wrapper on the desktop OS. This is great news for the upcoming Windows 8 tablet user and market. For me, for now, it feels like my phone UI is getting in the way of my desktop UI. I’ll probably get used to it later, but for now it just feels strange.

In any case, the press release and the little demo video seems to answer three primary and critical questions. Here are my first impressions and a few key frames from the video to tease you into watching it.

What is a Windows 8 App?
Based on this press release and quick demo, we can assume that a “Windows 8 App” is a touch enabled HTML 5 and JavaScript application running locally on the IE 10 engine. This seems to directly integrate IE technology into the OS. I wonder if Eric Holder will care. I assume that if I can still make another browser my default, we’ll all be safe from the clutches of the U.S. Justice Department.

The touch enabled Start Desktop

What is Windows 8?
Aside from assumed improvements in the kernel, driver infrastructure, etc., we learn from this demo that the primary target UI is the touch interface with cool split thumb-friendly touch keypads for all platforms. Of course support for the 20th century input devices formerly known as the keyboard and mouse continues to be available. Behind the new touch enabled "Start screen" with smart app tiles, the old "Start button and menu" and desktop interface can be found underneath the covers. So you can have your touch-cake and eat your mouse and keyboard driven app-cake too. Smart.

Dragging the next desktop pane into view. Note the distinctly non-Windows 8 Word icon.

What Should a Developer Know About Windows 8?
In addition to your bag of tricks you currently maintain, you'll need to add HTML 5 and JavaScript if you don't already have them. And if you are not already learning HTML 5 and getting past the 'alert' statement/method in JavaScript, you are standing on the dock and the boat is hoisting anchor. Get with it. Buy some books. Watch some tutorials. And start writing your own "Hello Touch World" Windows 8 App now.

Tweet in your Windows 8 App while balancing the budget in your mundane Excel spreadsheet.

It will be fun to watch this latest incarnation absorb some of the best of its competitive predecessors. It will be more fun to read about their indignation. It will be less fun if Microsoft prematurely releases and we have a Vista-like PR disaster regardless of the basic goodness due to a few unpolished bits. Either way, I’m heading back to my HTML 5 and JavaScript study group.

HaHa! HaHa! HaHa! HaHa! HaHa! Ha!

To the Mac community, all I can say is, will you now please SHUT UP about your “secure” OS.

Welcome to the real world of being a target and having to take measures to protect yourself. Now that you have realized your security was never security but obscurity, perhaps we can all have an adult conversation about battling the bad guys together instead of us having to listen to you crow about your false sense of superiority.

When you can't drive and you can't see over the back seat, you must trust the driver. The measure of that trust is determined by what you do when you are late. This is the conundrum of does and doesn't.

Effective management is simply pushing the right buttons and pulling the right levers at the right time. This requires sufficient information, analytic thought, rational decision, and consequential action. Asking questions and thoughtful contemplation are not enough. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.

1. Sufficient Information
    
2. Analytic Thought
    
3. Rational Decision
    
4. Consequential Action

Every healthy human being manages something. You wake up hungry (information) and you think about bacon (thought) and you decide to limit yourself to two pieces (rational decision) and you throw three pieces in the pan (consequential action) just in case one of them burns even though you know you’ll eat it anyway. Okay, we’re not all perfect managers. Actually, I’ve never met one, so I’m not sure there is such a thing. Excuse me while I take a break to finish that third piece of bacon…

What the world needs is yet another blog post on how to manage software development, so why not write it myself I ask. Unable to find a good reason to stop here, I’ll give it a shot. If you continue to read, you and you alone will be responsible for anything you might learn.

There are books, graduate courses, and no end to rambling blogs, so I’ll shoot for brevity and clarity here in Part 1.

1. Know Your Team
   Computers do not yet write software all that well by themselves, so you’re stuck managing the people. Your process or you dictate what they will work on and, by virtue of time constraints imposed, how they will work on it; this is the essence of management.
    
2. Be Decisive and Take Action
   Collaboration is a meaningless waste of time unless it is followed by real decision and actions that lead to positive results. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.
    
3. Be Honest and Fair
   If you say one thing to your team on one day and deny having said it the next day, your team will lose confidence in you and rebuilding that trust may not be possible, so choose your words and promises carefully. And if you make a mistake, admit it readily and apologize where appropriate. Your team will see this as a mark of a true leader.
    
4. Demand Accountability
   When you assert a process rule, enforce it. Hold team members accountable. Start with gentle reminders and further training but do not allow repeat offenders to skate without consequence. If you do, your process is not a process and it will fail.
    
5. Eliminate Needless Meetings
   Developers generally hate meetings with good reason. Most meetings lack an agenda, lead to no discernable action items, and there is rarely a copy of the minutes minutes and action items distributed to attendees. Most software development requires long, uninterrupted periods of time to effectively solve problems and complete complex tasks. Useless meetings in the middle of the day can ruin a developer’s entire day, throwing his productivity into a spiral, so group meetings into a single day where possible to eliminate or reduce the disruptive effects.
    
6. Review Everyone’s Work
   You may not understand the code, but having a developer walk you through the code, discussing the decisions made and showing off just a little will go a long way toward educating you and inspiring your developer. Review and discuss documentation, designs and test plans with interest. Spend the time to learn from and guide your team.
    
7. Get Yourself Out of the Meetings Cyclone
   Decline a leadership training or management committee meeting from time to time in order to do some real managing. Remember, the word “manage” has its root in manus (hand). If you don’t put your hands on it, you can’t possibly manage it.
    
8. Create and Shepherd Processes
   Everyone knows how to manage and can do so if you give them a process that establishes guidelines for what information should be considered, what decision making process should result, and how those decisions will become actions within the constructs of the process you have created.

Well, that’s enough for part one. More on the same topic later.

This morning I read a post by Seth Godin, a favorite of mine, which presented and discussed an essay written by Paul Graham of Y-Combinator called Maker’s Schedule, Manager’s Schedule.

I regret that this cogent essay and essayist have escaped my notice until now. It reveals what every programmer knows and has experienced with regard to meetings, and I’ve never found a better treatment of the subject.

It confirms with clarity that programming is a creative art, an act of creation or making. Such work cannot be effective and productive with multiple disruptive meetings every day. And sometimes it only takes one meeting, even a short one, to blow your whole day.

Why?

The content and contention in a single meeting can serve to distract a programmer to the point of rendering him effectively useless for the remainder of the day. This is true not only for the programmer but for anyone whose primary function is to make things of complexity.

Consider preventing the daily standup from becoming a meeting in which the resolution of identified impediments is attempted. And never allow the standup to devolve into an ad hoc project status review and planning meeting with the question, “When will you have X feature done?” being asked.

Consider piling all such meetings to which makers must be in attendance into one single day of the week, perhaps Friday or Monday to ensure the largest contiguous uninterrupted period for making, preferably in the late afternoon, so that we get every ounce of making from our makers that the company’s hard won cash can buy.

It’s more than something to think about. It’s something a manager could manage if the manager simply chose to do so, and it’s something a maker would appreciate more than can be expressed in written word.

I’ve long been taught and believed that the truth will set you free. But fear is a powerful counter to belief, especially when that fear is rooted in the compellingly powerful human instinct to survive, to preserve your livelihood.

I was reading Ken Schwaber’s The Enterprise and Scrum today and came across the following passage which I deeply appreciated. Ken is writing about to the development team’s fear of telling the Product Owner that they cannot deliver on their commitments for a Sprint.

When I discuss this kind of fear at the courses I teach, the attendees’ own fear is palpable. The soon-to-be Scrum users don’t think that the transparency, or truth, is acceptable where they work. They tell me that they will be fired if they tell the truth. Truth isn’t what their customers want to hear. They tell me their customers will find someone else who will lie to the them if they don’t. I have seen this in class after class for five years. People in product development think that their customers want to hear news only if it is good news and would rather hear a lie than the truth. “Lying” is a harsh word. But what else do you call saying that something is true when you know it not to be true? What else do you call misleading someone with information or holding back information that would have led them to better decisions? The Product Owners want to believe in magic, and the developers support their belief by lying. “Can you do this project by this date?” “Sure, no problem.”

The developers are aware of the complexities that cause changes to their original estimates. They are aware that the customer is unhappy. If a project manager is approached by a customer 60 percent of the way through a project and asked how the project is going, the project manager doesn’t really know. She knows that some things are going well. She also knows that some things are not going so well. She also knows that she hasn’t checked up on some things that could prove critical. However, saying “I don’t’ know” is unacceptable, so project managers have learned to say, “Right on,” “Right on target,” “Piece of cake,” or anything equivalent that will get the customer to go away and leave them to try to get everything on time, on cost. Basically, they lie. It is simpler than exposing all the nuances and complexities that add up to “I don’t know.”

Project managers might also believe that lying saves time. But because Scrum relies on transparency, misrepresentation undercuts the entire application of Scrum. If the Product Owners do not know exactly where things stand at any point in time, they will be unable to make the best decisions possible about how to achieve their goals. They need the best information possible, whether they view it as good or bad.

I don’t know anyone in this business who cannot relate to Ken’s assessment. I am coming to the conclusion with every additional year I spend in the role of code monkey that anyone, with proper preparation and context, can handle the truth, even non-technical folk. I am learning to reject the often held notion that these people are just not able to appreciate the nature of complexity.

Yes, Product Owners not only must have the truth but in fact they can handle the truth even when the truth is not welcome news. I have seen Product Owners ignore the truth but I have never been fired because I told the truth. What Product Owners have a very difficult time handling is the sudden discovery of the truth after having been lied to for long periods of time.

Whether we choose to tell the truth from the start or to lie to ourselves and our Product Owners, eventually, as the Bard would be wont say, the truth will out.

So I still believe that the truth will set you free. Fear will leave you miserable and in chains with the secret knowledge that the truth will be discovered sooner or later by those from whom you’ve hidden it. Freedom is so much easier than we sometimes think.

Nothing in this post is original. It’s just my reduction of the principles of class design from Uncle Bob in his Principles of OOD. If you don’t want to read, listen to the Hanselminutes interview with Bob. I just want to record my thoughts on these items here for posterity.

SOLID is just another acronym but if you are writing code it’s one you ought to know about.

SRP – Single Responsibility Principle: “A class should have one, and only one, reason to change.”

OCP – Open Closed Principle: “You should be able to extend a class’s behavior without modifying it.”

LSP – Liskov Substitution Principle: “Derived classes must be substitutable for their base classes.”

ISP – Interface Segregation Principle: “Make fine grained interfaces that are client specific.”

DIP – Dependency Inversion Principle: “Depend on abstractions, not on concretions.”

These are not new ideas and I’ve not visited these lately nor can I claim to practice these principles in everything I do. In fact, I’m sure that I don’t, but I am convinced that the more I follow these principles, the better my code will be.

I’m going to spend the next few days reabsorbing these and reading the PDF docs on the www.objectmentor.com site. If you want to follow along with me, start at the top of this post and follow the links.

Happy reading!

We are looking for a very technical enterprise meetings architect for a large, well established organization in the Washington, DC area. You need to have extensive meetings orchestration experience and be an expert with PowerPoint-centric meetings architecture. You should also have some experience with multimedia animations playback. Advanced direct, teleconferencing and mixed-setting slide or teleprompter reading skills also desired.

A qualified candidate should be an expert in all aspects of the PowerPoint slide development process, including advanced transition and animated playback techniques. Candidates must possess dynamic monotonal verbal script delivery skills and be able to work well within large and sparsely attended meetings. Candidates must be able to translate business meeting requirements into technical meeting architectures and designs while leading a team of meeting engineers in the rapid development, testing and deployment of complex, content rich PowerPoint presentations.

Candidates must have a real passion for PowerPoint and be self-directed, confident and able to perform the task of expanding relatively simple content in thousands of pages of written documentation to accompany large slide decks packed with dense, monotonous text. Candidates should have a face and be able to articulate the written word clearly and in bold tones. Candidates should also be familiar with modern pointing devices such as laser pointers in addition to traditional uses of the stick and index finger to provide emphasis when presenting the finished meeting product.

Meetings Architect Specific Duties:

• Mastery of building and maintaining enterprise meetings frameworks in response to business needs.
• Mentor meetings development staff while implementing best practices and improving meetings design and development processes.
• Work closely with business principals to understand enterprise meetings requirements.
• Translate meeting requirements into workable meetings architectures.
• Present tested, production ready meetings to executive staff for deployment in the field.
• Accompany executive presenters in the field to provide advanced PowerPoint backup and support in critical presentation delivery scenarios.

Required Skills and Experience:

• Ability to apply a broad array of skills and technologies to solve meeting presentation problems.
• Ability to utilize PowerPoint, all versions, and Windows Paint and screen capture tools.
• Ability to rapidly convert a one page outline or two minute conversation into a 60 slide presentation and 230 page accompanying notes and documentation handout.
• BS in Library Science or English or equivalent technical training and professional work experience.
• A minimum of 8+ year's cumulative experience developing enterprise meetings on the Microsoft PowerPoint platform and other technologies i.e. Windows Paint, etc.
• Ability to troubleshoot and diagnosis complex PowerPoint problems.
• Strong composition and obfuscation skills, as well as excessively verbose written and verbal communication skills.

Submit your resume today!

Before you make up your mind about LightSwitch prior to beta release, watch the new video on Channel 9. Before you decide that LightSwitch is for non-developers, watch Joe Binder in this video extend a LightSwitch application with a Silverlight user control and a custom WCF RIA Service.

The key point, I believe, made in the video is that EVERY LightSwitch application is essentially a 3-tier application. The extension of the Data Access tier with WCF RIA Services makes it possible to extend those tiers into the enterprise infrastructure easily.

The demo also makes a very important point. When you write a real LightSwitch application, you will be writing code. While LightSwitch might be appealing to non-professional or hobbyist or business types, whoever uses it successfully will in fact end up writing code. Will they have to be an expert developer. Not if they have support from the enterprise pros that build the infrastructure for the business.

I still want to see and play with the beta before making up my mind, but what I’ve seen so far looks very promising.

Two days ago, Microsoft unveiled Visual Studio LightSwitch. I heard about it first on Somasegar's blog and have followed the chatter and the growing list of blog posts and comments. I watched the Channel 9 preview video and the VS Live keynote video introducing LightSwitch. And then I watched them again making notes.

I'm deeply disappointed in a number of bloggers I regularly read and their many commenters that have parroted their sentiments. I won't name them here. Their negative reactions demonstrate an ill informed prejudice and predisposition to discount all 4GL tools without careful analysis and thoughtful evaluation.

Based on my careful notes of the demo videos and "official" blog posts about the tool, these bloggers and many commenters have made statements and critical judgments of LightSwitch that are demonstrably false or grossly inaccurate. And the first early beta is not even available yet. This rush to judgment ill becomes the professional stature and experience of these otherwise well respected members of the .NET development community.

From a certain point of view, I understand the nearly autonomic reaction of these .NET development community leaders. Professional developers have long dealt with the problems that so often plague solutions created by a host of desktop 4GL tools such as Access, FoxPro, FileMakerPro, PowerBuilder and many others. These tools have been highly successful in the business world seeking to just get something working that they could afford. In enough cases to be considered a plague by many professional developers, these solutions have far exceeded their limits as the business grew and ran into some of the hard and harsh limitations of these tools.

Many professional developers have been put into that crucibal of having to tell the business owner that their pet solution will not scale, has to be completely rewritten, and the effort will cost mega dollars to get a similar solution that will scale and grow with their business. The business owner doesn't want to spend the money, so he insists that the developer just make the 4GL solution work. Happy developers then fire their client. Needy and miserable developers then swallow their pride and spend more hours in frustration dealing with a 4GL too they come to hate more often because the solution wraps around a database that was designed by someone who thinks of dinner when you say the word table.

Scott Adams owes his fame and fortune in no small part to the advent of ill conceived 4GL tools and the more horribly designed solutions created with them by the pointy haired bosses who fancy themselves tech savvy.

So I understand the rush to judgment, but the facts are not there to support the negativity and biased ignorance I've seen in so many recent blog posts and comments.

Anyone can actually take the time to watch the videos and read the official blog posts and carefully consider what they have learned. Any professional presented with a tool for solving a problem that has never been satisfactorily solved in the past who automatically dismisses the latest attempt does himself and those who respect his opinion a disservice.

Here is what I've learned after reviewing the demostrations and taking detailed notes and carefully considering the possibilities without making invalid comparisons to the host of 4GL tools on the market today.

• LightSwitch is NOT a 4GL in the traditional sense of closed source, desktop bound, proprietary database, with few if any extension points.
• LightSwitch is a set of .NET assemblies and Visual Studio designers and project templates that produce a model based on XAML from which a Silverlight 4 and WCF RIA Services solution is generated.
• LightSwitch is a .NET solution and can be extended in Visual Studio Pro (and up) with standard Silverlight control projects and server side support projects.
• LightSwitch supports three data sources: SQL Server (and SQL Azure), Sharepoint 2010, and most importantly WCF RIA Services. In fact, SQL Server access in the 3-tier solution is done via WCF RIA Services and Entity Framework. I was not able to determine exactly how Sharepoint access is supported under the covers but would assume that the same solution is generated, with WCF RIA Services providing access to the Sharepoint list libraries and other Sharepoint data on the host server.
• There is certainly an incoherent marketing message from Redmond on the subject of the target audience but it is clear that while marketing speak would have business buyers believe that they will be able to write applications without code, the fact is that some coding skill will be required to write even the simplest of applications in LightSwitch where commonly found business rules such as validations and computed values on existing data sets are required.

Based on what I've seen so far, it seems the sweet spot for LightSwitch might be the entry level developer or what one blogger called the "productivity developer" with professional support from senior developers and architects constructing back end systems, designing databases and providing safe and simple WCF RIA Services for the less experienced developer to consume to deliver line of business applications that may never need the skilled hands of the top notch developers.

I want to learn more about LightSwitch and see it and play with it before I make up my mind about its usefulness. I want to see how easy it is to extend and expand a LightSwitch application in Visual Studio Pro as promised but not demonstrated. I want to learn more about the extension points. And I want to see and perhaps participate in providing constructive and informed feedback. More importantly, I want to see what the Microsoft team does with that feedback.

Bottom line. It's far too soon to judge. Let's get the beta and provide Microsoft with some constructive feedback instead of the diatribes I've seen so much of in the last couple of days.

My absolute favorite feature of Visual Studio 2010, so far, is the javascript Intellisense support via the <reference> tag. Add the following line to your .js file and you get jQuery Intellisense.

    /// <reference path="/scripts/jquery-1.4.1.js" />

My second favorite feature, so far, was just added with the Visual Studio 2010 Pro Power Tools just released by Microsoft the other day. It is the Add Reference Search feature. Behold…

There are a bunch of very cool features added by this small but powerful extension pack, but not having to scroll through a list of assemblies to find the one I’m looking for is a godsend.

You can read about all the goodies on the download page, but two other honorable mentions are:

Ctrl+Click is now the equivalent of right click and selecting Go to Definition. Booyah!

Ctrl+Alt+] on a selected block of assignments will align the = operator making your code block far more readable.

I highly recommend this extension. Thanks Microsoft!

If you leave your door unlocked and someone enters your house for nefarious purposes, can you blame your lock manufacturer? Will you switch to a new brand of lock? Or if you open the door and pickup the the strange package you weren’t expecting from your doorstep, take it into your home and open it, do you sue the contractor or architect who built your house when it explodes? Do you declare your house to be unsafe and abandon it to live in a shed?

Well, it seems that if you’re Google, you do.

PC World reports today that Google has announced by leak that they will abandon Windows, blaming Microsoft for the Chinese invasion they suffered in January. Anyone with the slightest bit of brains knows this is an economic and political stunt and has nothing to do with security. The Trojan that Google claims allowed the Chinese hackers into their computers was, according to Symantec, entirely preventable.

Now, five months later we learn that rather than admitting the embarrassing fact that they either left the door unlocked (had un-patched machines) or invited the hackers in (opened attachments on vulnerable machines), Google is announcing that they will toss out their rival’s OS to spite their own face. Instead they will jump on the Linux for the Desktop and Mac OS bandwagon.

That’s fine. It’s a free country. But Google is just as big a target now as they were then and any honest security expert will tell you that Linux and Mac OS vulnerabilities exist and are ripe for exploitation. When Google is attacked again after having put its head in the sand, who will it blame then?

The bottom line is that you cannot blame your security failures on the lock manufacturer or the contractor who built your house if you’re not even willing to lock the door or question the anonymous package left at your doorstep. This is Google’s folly. They have opted for an effectively placed marketing jab against an opponent while leaving their left flank exposed for another Chinese hack attack. When it comes, will they blame the President of the United States or the Secretary General of the U.N.? Or will Google take responsibility for its own security?

Lately I've become alarmed at the negative level of my thinking at times with respect to my work which can then spill over into my personal life. I've been wondering how I can more consistently harness all the latent energy in the pressure to deliver within the constraints of limited resources, tight deadlines and even tighter budgets and convert that to more positive thinking.

I know the value of positive thinking and the resultant self-reinforcing confidence. It leads to greater achievement, productivity and happiness. And yet negative thinking can so easily overwhelm us when the deck seems stacked against us.

I was pondering this question when I remembered a post from Seth Godin called The Problem with Positive Thinking. Here's part of it:

“All the evidence I've seen shows that positive thinking and confidence improves performance. In anything. ... Key question then: why do smart people engage in negative thinking? Are they actually stupid? ... Negative thinking protects us and lowers expectations. ... If positive thinking was easy, we'd do it all the time. Compounding this difficulty is our belief that the easy thing (negative thinking) is actually appropriate, it actually works for us. The data is irrelevant. We're the exception, so we say. Positive thinking is hard. Worth it, though.“ (Seth Godin, September 2009)

Tomorrow, I will actively think more positively. I will lay aside negative thoughts and entertain only the positive. I will convert and harness the energy of the pressure to deliver and channel that energy into positive, productive valuable thinking. Wish me luck!

Do you have a hard time making decisions? Even the most decisive of us can get caught in the headlights of the oncoming project train, unable to choose left, right or straight ahead. Here’s a few strategies that I’ve found useful and sometimes forgotten about while stuck on the software development analysis thought pot.

1. Ready, aim, fire! Research, evaluate, decide. Hesitation breeds doubt. Doubt is the father of indecision. Make a reasonable degree of confidence your standard and avoid looking for absolute guarantees. There are none.
    
2. Put away fear of failure and accept the fact that there is more than one acceptable outcome to life’s challenges, including your project. Learn from mistakes but don’t be too afraid to make new ones.
    
3. Begin. Make a start. Act. No journey or decision can ever be taken without the first step. Make a small decision, take action and then improve on your progress by evaluating regularly. Take digestible course correction decisions. Don’t derail your project by overcorrecting and rolling the bus at full speed.
    
4. Set a decision deadline and stick to it. Lay out an incremental research and evaluation plan with a list of questions you need answers to in order to make your decision. If you don’t have a perfect answer, enumerate what you have anyway and incorporate it into your final decision.
    
5. When the problem is too big and the decision too overwhelming, break it down into smaller, more specific pieces. Apply the strategies you find effective on the more manageable elements. Do that until you’ve put all the pieces together and before you know it, the puzzle will be complete.
    
6. If the outcomes of the decision, regardless of the choice, are equally acceptable, flip a coin. Move on. Don’t waste time dwelling on equally acceptable paths to different but relatively satisfying conclusions.
    
7. Go crazy. Make a choice even if you don’t have a reasonable level of confidence. Get off the ice berg and start swimming. Something will happen and that will lead to something else. It might turn out to have been a mistake, but at least you’ll have momentum on your side. A moving car is far easier to turn around than one that is parked.
    
8. Put things into perspective. This project decision you’re worrying about, the one keeping you up at nights. Can it compare with watching your kid’s school play? Will your client attend your kid’s wedding? Or your funeral? Beyond successful completion or abject miserable failure on the project, will the outcome have a permanent impact on your life in the long term? Will it matter to your grandkids? Perspective can be a powerful decision making tool.
    
9. If you can’t take the plunge off the high dive, run an experiment. Try out your decision on a smaller scale. See what happens. Take the results and boldly make the real decision.
    
10. Change your point of view. Look for a distraction. Take a walk in a Japanese garden. See a movie. Read a good book. Take your wife on a date. Go to church. Do something to get away from it all, even if just for a few hours. Then come back with a few oxygenated brain cells and make a decision. Ready, aim, fire!

What strategies have you found useful when stuck, unable to make a critical choice on a project? I’d love to hear from you.

Update: I know these are generalized platitudes, but sometimes a good platitude can spark the inspiration one needs to find a specific solution to a real problem.

In his annual letter to shareholders, Warren Buffett wrote (emphasis added):

“We tend to let our many subsidiaries operate on their own, without our supervising and monitoring them to any degree. That means we are sometimes late in spotting management problems and that both operating and capital decisions are occasionally made with which Charlie and I would have disagreed had we been consulted. Most of our managers, however, use the independence we grant them magnificently, rewarding our confidence by maintaining an owneroriented attitude that is invaluable and too seldom found in huge organizations. We would rather suffer the visible costs of a few bad decisions than incur the many invisible costs that come from decisions made too slowly – or not at all – because of a stifling bureaucracy.”

There are times when working in an enterprise can be frustrating because there are individuals who deliberately and regularly hinder your work while hiding behind the plausible deniability and comfortable safety of that stifling bureaucracy of which Warren Buffett so sagely speaks.

The question is what to do when you find yourself in that situation. There can be only three answers, I believe. Either you succeed in spite of the efforts of well seasoned bureaucrats and hope that attrition wins the day or you fail while trying or even give up somewhere along the line, resigning yourself to failure. The third alternative is that you find another ball field and another team on which to play and never look back.

Which one would you choose?

I rarely just parrot-link another blogger’s post, but I’m going to make an exception here to give props to Chris Sells and his excellent “The Performance Implications of IEnumerable vs. IQueryable.”

Chris, the venerated Microsoft Legend, walks us through a great example of where the use of IEnumerable vs IQueryable can get you into trouble. With a simple swap, Chris goes from returning every row in a table to a simple count(*).

The critical thing to learn is that IQueryable is “composable” meaning that you can make one from another before executing the final “outer” query and having the composed expression parsed and executed.

One additional note, however, is the gotcha that can bite you on the keester if you’re not careful. With an IQueryable dependent upon a data context, don’t lose the context or you’ll end up with:

ObjectDisposedException: Cannot access a disposed object. Object name: 'DataContext accessed after Dispose.'.

So watch out for the dangling context. :)

The question of the value of third party UI libraries has often come up in my career. At one time I was an eager advocate of using a comprehensive UI library. Now my attitude is a bit more pragmatic.

Third party UI libraries are sometimes a boon and sometimes a bane. Even for well seasoned UI frameworks. UI libraries for web applications tend to be particularly troublesome because they so often have a clumsy, heavyweight configuration and API that end up requiring more time to use than they save while the vendors race to win the feature count contest.

For some years, the trend seemed to lean toward the use of UI libraries because building a UI by hand was hard regardless of whether you were working with spaghetti script or with Win32 and MFC. Now Microsoft's toolset supports a much richer set of UI paradigms making the delivery of a great UI much easier right out of the box. The trend seems to be gravitating away from reliance on third party controls toward a more simplified user interface style with a more elegant framework relying more on convention than a feature bloated configuration and black box API.

One area where UI libraries seem to continue to do well, in my view of course, is with Silverlight and WPF (XAML) applications. These UI frameworks and their supporting third party UI control sets seem to have been made for each other. Both rely heavily on the powerful UI declarative language XAML. The rich user interfaces that can be spun up using Silverlight or WPF can be intoxicating.

Ultimately, we need to use UI libraries judiciously, being careful not to overuse them where requirements and the effort needed to learn and configure them are not warranted. One could argue that the limited way in which many third party controls are used in a variety of applications provide us with a bountiful set of examples of the gratuitous overuse of these libraries. Sometimes all you need is a good closet and the kitchen sink that comes with that room builder toolkit is just plain old overkill.

I love Orson Scott Card’s books. My first and still all time favorite is Ender’s Game.

If you’re not a fan, go read the book anyway. If you are, you already know what I’m talking about. The iPad is Ender’s desk, or perhaps its precursor.

Here’s a composite I just made thinking of this concept. One image from Apple and the other from a very innovative early childhood education software company called Imagine Learning.

I’ve never wanted to own an Apple produce product (slip of the finger, but an apple is a fruit after all) or develop software for it until now.

When I think of the amazing ways that educational content and interactivity could be delivered to students using this device, I get very excited. And I imagine a very smart kid hacking the device and sending rude messages to another student. That makes me more excited for the future of technology than anything I’ve seen lately.

The .NET technology map keeps expanding, but I have my eye on one particular continent, a little piece of the .NET 4 world I’m calling the Silverlight 4 Enterprise Stack. There seems to be focus coalescing on this important piece of technology real estate.

The Patterns & Practices team blog has a great post looking into the enterprise crystal ball. Be sure to check out their Prism (Composite Application Guidance) on CodePlex.

The primary pieces of the Silverlight 4 Enterprise Stack are:

• WCF RIA Services
• Model-View-ViewModel (video)
• Managed Extensibility Framework

Other supporting players in the stack are:

• Entity Framework 4 (and other LINQ DALs like PLINQO)
• Windows Workflow Foundation 4

With the eminent release of these technologies on April 12, we the Enterprise Software rank and file have much to look forward to in terms of new toys to play with while delivering some amazing new user experiences in the enterprise world.

If you want to keep tabs on the Silverlight 4 Enterprise Stack, be sure to set your RSS reader to tap into these key bloggers:

• Brad Abrams
• Mike Taulty
• Tim Heuer

For us enterprise software geeks, the year 2010 is shaping up to be a very good year!

Let’s face it. Most of us code slingers have no innate understanding of what makes a great user experience (UX) design. We spend so many hours in front of multiple user interfaces that navigating and using software becomes virtually intuitive, instinctual. But we are not “normal” users.

I’ve just finished reading and mean to re-read Whitney Hess’s “25 Guiding Principles for UX Designers” on Inside Tech. It’s a great piece with some very good references. I recommend you read the entire article multiple times. Here are some of my favorites (my number is not the same as Whitney’s):

1. Understand the underlying problem before attempting to solve it.
How often do we just begin coding and throwing a user interface together without having spent much, if any, time with the target audience to understand their needs, challenges, skill level and approach to solving the problem currently?

2. Make things simple.
How often do we try to put every feature we can pack into a single view thinking to make the software powerful and reduce round trips to the server or some other resource?

3. Provide context.
How often do we place controls or information in a user interface that we consider convenient but in reality is out of context and will confuse a user who does not understand what is going on “under the covers” so to speak?

4. Be consistent.
How often do we design one page in a certain way only to bounce the user to another page in a web application that uses a different design paradigm, making the user spend some time just to figure out where the OK or Cancel button or link is now?

You can read about these and the 21 principles at Whitney’s article (see link above). I also recommend the following resources, a selection from those Whitney recommends:

UX Principles and Design Guides

• Google
• Windows
• Facebook
• U.S. Government
• Jakob Nielson (King of Usability)

If you have some favorite principles of your own, please share them here.

I’ve been giving the question of why software teams fail some considerable thought in the past few days. Reading Brad Abrams’ post Don’t Waste Keystrokes and his statement that “By far the biggest problem I see on teams of > 1 is communication” led me to compile the following list. Here are some of the reasons, in addition to the most important one that Brad pointed out already, that a software team, or any team really, fails:

1. The team does not practice regularly, no coordinated learning.
2. The coach does not know the strengths and weaknesses of the players.
3. The players do not know their role, their zone or the plays.
4. The players do not get along, they are not one in purpose.
5. The players do not trust or respect the coaching staff.
6. The coaching staff puts players with no skill on the starting lineup for unknown reasons causing resentment amongst the other players and guaranteeing a loss at game time.
7. The players do not believe the coaching staff understand the game.
8. The players are more focused on individual agendas, they do not work together to win.
9. The rules of the game are not well understood and change during the game.
10. The coaching staff and team captains disagree on how the game should be played.
11. The coaching staff recruits new players looking for players who will agree with their ideas rather than seeking out players who can actually play.
12. The players fail to improve their skills on their own time.
13. The players lack motivation and fail to come to practice and give only a half-hearted effort in the game.
14. The team captain spends more time arguing with the coaching staff than he does leading and motivating the players.
15. Winning becomes secondary to just finishing the season.

If you can think of any others, please let me know. And if you have ideas for how to fix these situations, I would love to hear from you as well.

Documentation neglect is a chronic problem in most enterprise application development efforts. This problem is unrelated to the selected development methodology but there are some who assume that agile methods eliminate documentation despite the agile manifesto's declaration that we value "working software over comprehensive documentation." It does not claim that documentation is not needed.

In my own work, I've found that comprehensive documentation authored by well meaning individuals, or worse a committee, who possess very little technical expertise, is often written in confusing, lengthy narrative style that requires a linguistic anthropologist to decipher. Too often development teams spend days pulling out the real features and requirements and expected behavior from such documents, generally resulting in many unanswered questions, the answers to which just cannot be found in the comprehensive documentation.

Recently we have found greater value in documentation that has relatively strict structures that guide authors to produce specific, detailed and comprehensible documentation. The format is simple and adopted from the increasingly popular behavior driven design (BDD) approach.

The goal of this approach is to define desired behavior and clear acceptance criteria for specific requirements without mashing them all together in a narrative style that requires time consuming decomposition. Here's the format:

+++++++++
P[n]: Process Title
Two line description of a process (akin to epic user story)

F[n]: Function Title (a feature or step in the workflow)
As a role
I want action/process description
so that benefit/value of feature.

AC[n]: Acceptance Criteria or Scenario Title (p1)
Given some initial context (the givens),
when an event occurs,
then ensure some outcomes.

+++++++++

It's really not different than BDD. There is only one subtle difference which I've found can make all the difference in the world. the terms used (process, function and acceptance criteria) are far less scary to the business than terms like epic, user story and scenario.

Of course, this won't work for every situation, but where you can break documentation down into logical units that focus on one feature, one thing at a time, you can eliminate the time consuming deconstruction of comprehensive documentation that can only be processed by the most advanced computer in the world: the human brain.

I’ve not used this blog for politics in the past, but I’m going to start making some exceptions where I think there is a technology tie-in. George Will’s piece on the Copenhagen summit was very interesting. I recommend that you read it. I am not a climatologist but I am a skeptic of all science based on computer models, especially models that cannot accurately predict the present observable state of a system.

The recently hacked emails of the Climate Research Unit (CRU) in Britain reveal a pattern of behavior that would be more consistent with the corrupt leaders of a cult whose proclaimed tomes of divinely inspired scripture cannot withstand scrutiny should certain facts be revealed. In the minds of the true believing disciples or the corrupt leadership of the cult, the ends justify the means. And truth is not a consideration.  

The software models and data upon which all climate change disciples rely are written by flawed human beings. Whether a software engineer expertly writes the software to implement his best understanding of the requirements of the scientist or the real scientist writes the software with a less than perfect knowledge of software engineering and design, the outcome is the same. (Hey, not even a PhD can know everything.) All software is flawed. It is the nature of our art.

Can computer models be a good thing? Sure. Especially when they work. Can they be a bad thing? Well, consider that a climate model must model the entire earth and its atmosphere. That’s a few million data points (colossal understatement). These models must have historical data. And there’s the rub. It’s not there. Not really. So we extrapolate the data using tree cores and ice cores and, wait for it, more computer models.

Any software engineer knows that such a model will be inherently complex and that complex systems are inherently flawed and that very complex systems are inherently very flawed. No software engineer will declare her (or his) faith in such a model or its output, but more importantly, they would never bet a week’s salary on it’s accuracy without full testing and confirmation against known observable data and repeatable tests. Yet, we are preparing to bet trillions of tax payer dollars on these flawed models. “Hey, Sam, keep your hands out of my pocket!”

The problem we have is that scientists have put their faith in software models and data produced by software models as the magical source of all truth and knowledge. They are either the corrupt leaders of a cult (see the CRU emails) or its blind disciples insisting on the truth of their models even when observable facts contradict and invalidate those assertions.

The climate change models and extrapolated data have become scripture. The scientists who preach daily from the pages of that holy writ are held in prophetic awe and reverence by the ignorant masses of well intentioned politicians and citizens of the earth. Except for software engineers and the “deniers” of course.

So back to the question. Can computer models be a bad thing? Yes, when the ignorant or the corrupt use them as an unquestionable, magical affirmation of their own political agenda or emotional response to the idea that man is killing the planet and that unless we do something about it, we will all die. Well nobody wants that.

Oddly, we ridicule and persecute religious nuts who do the same thing. I guess they just weren’t smart enough to get a PhD and call themselves scientists rather than prophets. Stupid nuts.

Silverlight WCF RIA Services Beta Released was released recently, replacing the preview bits I’ve been playing with. You can pick up the new beta here. I'm still using VS 2008 SP1, but I am using Windows 7, so I download directly from here.

WARNING! If you’re not on Windows 7 or Server 2008 R2, you’ll need the hotfix mentioned. If you're still on XP or Vista, let this be the final reason to upgrade and do it. You won't regret it.

I learned first about the beta release from Dan Abrams blog post. Some coolness he mentions:

• DataSources window. Drag and drop "tables" exposed by Domain Service onto the form.
• Simplified error handling on client and server.
• Data model inheritence flows through the Domain Service.
• Presentation model hides DAL model with CRUD support.
• Optimized binary channel by default.
• Integrated into Silverlight 4 installer.
• Handling of compositional hiearchy in data models.
• GAC and bin deployment, with bin taking precedence.
• Globalization support, user state and persisted sign in with updated Business Application Template.
• Go-Live bits for .NET 3.5 SP1 and Silverlight 3.

Another item of note is the name change with the WCF moniker. RIA Services is now part of the WCF services family along with ADO.NET Data Services. This seems like a convergence of technologies in an enterprise ready set of tools and services that will bring Silverlight into the forefront of enterprise application development and delivery.

I'll be working on pulling these new bits together and getting my "Aventure" blog sample back on track with the new Azure SDK bits and these new WCF RIA Services bits. Given the plethora of changes, I'll likely start over with fresh new project templates and pull what little customized code that might be needed from my previous blog post on the topic.

I am extremely impressed by the sage wisdom of Sir Charles Antony Richard Hoare's The Emperor's Old Clothes given at his acceptance of the Turing Award in 1980 and subsequently published by the Association for Computing Machinery (ACM) in 1981. Here are my favorite excerpts. I hope you will read the entire text using the link below.

"You know, you shouldn't trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd."
...
"Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution."
...
"At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way--and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay."
...
"The mistakes which have made in the last twenty years are being repeated today on an even grander scale."
...
"If only we could learn the right lessons from the successes of the past, we would not need to learn from our failures."
...
"To have our best advice ignored is the common fate of all who take on the role of consultant, ever since Cassandra pointed out the dangers of bringing a wooden horse within the walls of Troy."

The Emperor's Old Clothes
Sir Charles Antony Richard Hoare
Creator of the Quicksort algorithm
1980 Turing Award Winner
© 1981 ACM 0001-0782/81/0200-0075

Full text here in PDF.

Having accidentally browsed into this today, I reiterate the axiom that complexity is the enemy of sound software development and hereby recommit to following the path of simplification, learning more lessons from my successes to avoid more failures and to sometimes keeping my best advice to myself.

In anticipation of repaving my Vista x64 machine with Windows 7 after the MSDN release on August 6, I’ve prepared my wish list of hardware upgrades I’d like to do at the same time I pave the machine with the new OS.

Should the family financial officer (FFO) decline to approve my purchase request, I’ll at least sneak in the SSD purchase.

Update (new list, bigger appetite):

What plans do you have for your Windows 7 upgrade?

Drool….

Here’s the content of the most exciting email I’ve received lately (invite code redacted of course):

Thank you for your interest in Windows® Azure™.

Your invitation code is xxxxx-xxxxx-xxxxx-xxxxx-xxxxx.

You can now sign up for a Windows Azure account at http://lx.azure.microsoft.com/fs. Please keep this email in a safe place.

This invitation to participate in the Windows Azure Community Technical Preview is subject to the following usage limits:

        Total compute usage: 2000 VM hours
        Cloud storage capacity: 50GB
        Total storage bandwidth: 20GB/day

During the CTP, we reserve the right to suspend your account activity (this does not imply we will delete your cloud storage) if you exceed these usage limits.

Sincerely,
Windows Azure Platform Team

You have received this email because you registered as being interested in the Community Technology Preview (CTP) of Windows Azure. As a participant in the Windows Azure CTP program, you will continue to receive emails related to that program unless you end your participation by emailing azinvite@microsoft.com with “END PARTICIPATION” in the subject line.

To ensure proper delivery of future updates please add azinvite@microsoft.com to your address book or safe-senders list.

Microsoft respects your privacy. To learn more about Microsoft's privacy policy, please click here.

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

I’m very excited to begin learning to develop against Azure in all my spare time. If I learn anything worthy of note here, I’ll share it. Just too many things to dabble in and too little time.

With the release of Silverlight 3 on Friday, I’m wondering whether the enterprise (that mythical stereotype) will adopt Silverlight 3 for line of business (LOB) applications. The official “what’s new” section included the following items that I found very interesting:

Improving Rich Internet Application Productivity. New features include:

• 60+ controls with source code : Silverlight 3 is packed with over 60 high-quality, fully skinnable and customizable out-of-the-box controls such as charting and media, new layout containers such as dock and viewbox, and controls such as autocomplete, treeview and datagrid. The controls come with nine professional designed themes and the source code can be modified/recompiled or utilized as-is. Other additions include multiple selection in listbox controls, file save dialog making it easier to write files, and support for multiple page applications with navigation.
• Deep Linking. Silverlight 3 includes support for deep linking, which enables bookmarking a page within a RIA.
• Search Engine Optimization (SEO). Silverlight 3 enables users to solve the SEO-related challenges posed by RIAs. By utilizing business objects on the server, together with ASP.NET controls and site maps, users can automatically mirror database-driven RIA content into HTML that is easily indexed by the leading search engines.
• Enhanced Data Support Silverlight 3 delivers:
  • Element to Element binding : UI designers use binding between two UI properties to create compelling UI experiences. Silverlight now enables property binding to CLR objects and other UI components via XAML, for instance binding a slider value to the volume control of a media player.
  • Data Forms. The Data Form control provides support for layout of fields, validation, updating and paging through data.
  • New features for data validation which automatically catch incorrect input and warn the user with built-in validation controls.
  • Support for business objects on both client and server with n-Tier data support. Easily load, sort, filter and page data with added support for working with data. Includes a new built-in CollectionView to perform a set of complex operations against server side data. A new set of .NET RIA services supports these features on the server.
• Improved performance, through:
  • Application library caching, which reduces the size of applications by caching framework on the client in order to improve rendering performance.
  • Enhanced Deep Zoom, allows users to fluidly navigate through larger image collections by zooming.
  • Binary XML allows communication with the server to be compressed, greatly increasing the speed at which data can be exchanged.
  • Local Connection This feature allows communication between two Silverlight applications on the client-side without incurring a server roundtrip: for instance a chart in one control can communicate with a datagrid in another.

I’ve just downloaded the bits and will begin exploring the new controls and just how easy it is or is not to build applications. My only criteria at the moment is whether or not the applications are as easy to build as a Windows Forms application. Obviously there are far more important evaluation criteria, but I’m wondering whether my stated criteria here will be the more common question raised in the enterprise. That is, can we build apps faster, easier, better with this? If not, I’m not sure the enterprise will get too awfully excited about it unless a clear case can be made for replacing the often time consuming, error prone web application development process with a simpler Silverlight 3 development process.

One way or another, I’m excited about Silverlight 3 and eager to dive in and have some fun.

After a long search for the right business process management platform that would allow us to integrate and extend with .NET, my team selected the Ultimus BPM Suite. The primary factors in the decision were the comprehensive nature of the solution which would allow us to deploy process management without requiring the use of some other tool such as InfoPath or SharePoint. Additionally, the solution would allow an incomplete process to be deployed and have assigned "process experts" make final decisions about business rules that may not have been clear or available at the time the process was designed.

I spent all of last week at their North Carolina offices in a "jumpstart" training course and met many of the key players at the company. Good people all around. Their technical expertise and willingness to listen to our team's concerns were impressive. There were a few minor UI glitches that we brought to their attention such as some scrolling issues when designing a process with limited screen real estate. The Ultimus people were genuinely interested in our input.

Having initially found and recommended the product, I was even more impressed with the product as we went through detailed training that brought out a number of features and illustrated an architecture that gave me even greater confidence in the product. This was particularly true in the area of integration points with existing systems and the ability to extend the process using custom developed controls or even process context aware ASP.NET pages hosted outside of the process server.

Our only disappointment was that some of the the training session content could have been improved as at times some of the class members were left a little lost and fell behind. This was in part because the "jumpstart" course was designed to fit a lot of material into a few days, but it was in part due to a lack of maturity in the content and presentation. We were very candid with the Ultimus training director about this and he took our input eagerly and promised improvement. Based on my conversations with key Ultimus employees, I believe that will happen.

If you are looking for a better way to deliver business process management and enterprise human-centric workflow solutions, you should consider Ultimus. There were other systems that were much more expensive that may have fit our requirements, but this was the only one we found that allowed us the freedom to extend and customize using our .NET dev skills without requiring coding skills to design and modify and manage processes.

I'll be writing more about Ultimus as our experience with the product continues.

The following spam message (less the links) skipped through my spam filters somehow. If you are not a native speaker of English, this message may appear to be in order if your skill level with the language is limited. Otherwise, I suspect you will find this text as amusing as I did. I have not modified a single character. Enjoy...

welcome to order,
Our company is one of the largest wholesalers in Asia ,and we sell products to all over the world,we have the authorithed licence issured by Chinese government,all products in our company ranges from varieties of electronic products like mobilephone ,television, laptop,DVD,GPS,MP3/4 to photograph video game ,scanner, motorcycle prohector and so on..
We have earned our reputation in the world through our honesty business practice in the past years,and obtained many compliments from our clients globally.As we are the direct wholesalers for many reputable brands in the world,so all the products purchased in our website are promised to be at a lower price with the high quality,also all the facuty products will be returned within 7 days,exchange within 14 days,repair within 2 years without charge.
We will be right here waiting for your visitation.

I hope that as software architects and engineers we are producing code and other textual artifacts that communicate with greater clarity and understanding of the language and idiom in which we express our ideas. Do we write documentation as badly because we can only communicate clearly in code? Or vice versa? It is something to think about.

One of the latest Apple ads makes fun of Microsoft for spending more on marketing than on fixing Vista. Time for all you fruit computer junkies to face some cold hard facts:

Let's take our most recent SEC filing quarter for both companies and compare spending on sales, marketing and administration versus research and development and then average that spending per employee.

Microsoft spends about $25,000 per employee on R&D and $43,000 on sales, marketing and administration.
A ratio of 1 to 1.72.

Apple spends about $16,300 per employee on R&D and $51,200 on sales, marketing and administration.
A ratio of 1 to 3.13.

So relatively speaking, Apple spends nearly twice as much on sales, marketing and administration as Microsoft does.

And that's one reason why I'm a PC. You can keep your fruit computer.

I just posted this on a linkedin group to which I belong, but I thought I'd also like to pose the question here.

I'd like to get a discussion started that attempts to define enterprise software architecture. My own definition seems to be evolvoing with every enterprise for whom I've worked. In the abstract, for me, enterprise software architure is the art of putting the pieces of multiple puzzles together into one great work of art.

There are many puzzles to choose from and every enterprise has a unique mix. There are multiple teams with various skillsets and experience. There are multiple business processes sometimes with unique and strange business rules. Technology platforms that differ, communications protocols that won't communicate with one another, languages, frameworks, compilers, IDEs, components, and hardware that vary from team to team and department to department. Ours is the task of taking these disparate and often incongruous pieces and molding them into one coherent masterpiece of technology and human resources to get more done, get it done better, quicker, cheaper and easier. And if we do our jobs well, it may be that no one will notice that we did it at all.

What do you think?

I just posted the following note on a LinkedIn group I follow in answer to a post about so called "software factories," which is a nice euphemism for overseas developers working for much less than they deserve struggling to meet the unreasonable demands of their bosses. This represents my opinion on the subject:

Never forget that you get what you pay for. Hiring an overseas or even local "software factory" or consultancy to build your software can be problematic at best and a complete waste of time and money at worst.

First, if you cannot communicate, forget about it. Building software is 99% communication and 1% technology. Okay, perhaps I overstate the case. A little. But you cannot overestimate the importance of clear, effective communication.

Second, unless you have the internal people required to manage such a relationship, your project will fail. This means you need project management and technical people in your own organization that you know well and trust. They need to be supremely competent. This is especially true if you plan to hire a firm outside of your own geographical area.

Third, plan for time and budget overages. It is the nature of consulting to promise a low price and quick turnaround and then when you are committed to the project and it is "nearly done," you will be informed that there is much more to do, generally due to legitimate changes in requirements because you did not fully understand what you wanted when the project first began. This is the boon and bane of software development whether internal or external.

Finally, you can have success outsourcing your software development project, but do not make the mistake of thinking that it will save you an enormous amount of time and money, especially for a single application project. It takes time to develop a working relationship with an outside consultantcy, especially one that is half way around the world. If you have multiple projects, long term goals, and a huge budget of time and money, it may in fact be cost effective to have a relationship with a so called "software factory." But if you are a small organization and have one or two projects, you will nearly always be better off hiring a professional locally, usually through one of the many technical recruiting companies, to come into your organization as a contractor to work on-site building exactly what you want as you discover over time what it is you want exactly.

I upgraded to the latest version of dasBlog a few days ago and inadvertently allowed comments without requiring approval. A spambot comment got through and while I quickly turned on the "require approval" feature, it was too late. Since then I've been bombarded with stupid link spam comments. I even deleted the one post that seemed to be the bot target and created a new post with the same content.

No luck. After many similar spam comments today being posted to the most recent post on my blog, I'm giving up. I'm taking a comment holiday. It won't bother anyone really because I don't get many real comments. I'll enable the comment functionality some day in the future.

Meantime, if you have a comment, feel free to email me and I'll post it as an addendum to the relevant post.

Being rather new to Vista this week, I was sorely disappointed to see the severely dumbed down defrag utility in Vista. A pathetic effort. Really! So after a few highly scientific Google searches, I settled on O&O Defrag and could not be happier.

Here's the lame, incredibly useless UI in Vista's Disk Defragmenter. Note, if you are going to use some other defragmenter on a schedule, which I would recommend, be sure to disable the regularly scheduled Vista defragmenter by unchecking the box. One way of getting there is to go to the Control Panel and then Performance Information and Tools and then Advanced Tools.

And here is only part of the incredibly useful O&O Defrag UI, a shot taken as it defrags my drives:

Of course there are other suitable defrag tools such as DiskKeeper and others. Perhaps Microsoft wanted the Vista tool to cater only to the basic, uninformed user. If so, they certainly left the market wide open to the more sophisticated tools vendors such as O&O.

I finally took the plunge. Now I get to use 4GB out of 4GB except that the bare minimum I seem to be able to get Vista x64 down to is a 1.2GB footprint. And that's after hours and hours of experimentation and disabling some visual enhancements, though I feel no loss there and am experiencing a significantly reduced sense of loss.

Now I'm happy to be able to test on x64 virtual images using VMWare's Workstation, I'm afraid I may need to buy four 2GB sticks of RAM now. Despite the fact that the additional memory is available now, the larger footprint nearly wipes out the gain.

And that's without running any significant applications, except IE, which is quite a memory hog. I guess the old 640K upper limit days are over.

Yes, RAM is cheap. A quick check on Newegg.com and I found 8GB (4 x 2GB DDR2 800) for $174. I can't even buy three tanks of gas for my SUV for that.

I'm getting ready to do some serious MOSS 2007 architecture and development work. In the past, I've used Virtual PC 2007 to host a virtual development environment running a Windows server operating system, SQL Server, MOSS and Visual Studio all running in the same virtual machine. And I've never been very happy with the performance of that virtual machine.

So today I decided to give VMWare a try and downloaded VMWare Workstation 6.5. I installed Windows Server 2008 Standard x86 (full install) on a new virtual machine with the same disk space and memory as I had allocated for the same operating system install using Virtual PC 2007. I gave both virtual machines 30GB of disk space and 1GB of RAM. I'm running on a Core 2 Duo 6600 on an ASUS P5B at factory default speed with 4GB of RAM with virtualization support enabled. Both virtual machines virtual drives live on the same drive.

The major advantage of VMWare is its ability to utilize both cores where Virtual PC is stuck with using just one. I'm sure there are additional reasons for the differences in performance. I used PerformanceTest 6.1 from PassMark. I'm sure there are other ways to test virtual machine performance, but this seemed to be a reasonable though unscientific approach. I made sure my machine was running the same processes and completely idle except for the virtual machine host application.

I only ran the tests that mattered to me: CPU, 2D, memory, and disk. I don't care about 3D and CD performance for the virtual machine. Here's the results:

vmware		test 1	test 2	avg	ratio
	cpu:	326.6	344.4	335.5	2.2x
	2D:	28.7	32.2	30.45	3.3x
	Memory:	96.7	96.2	96.45	1.2x
	Disk:	469.1	454.5	461.8	6.4x
	Total:	921.1	927.3	924.2	2.9x
vpc 2007
	cpu:	150.7	154.1	152.4
	2D:	9.2	9.3	9.25
	Memory:	83.3	83.2	83.25
	Disk:	69.6	73.8	71.7
	Total:	312.8	320.4	316.6

 

I was amazed to see that overall, the VMWare virtual machine ran 2.9 times faster than the Virtual PC machine. Even more amazing was the performance improvement of the 2D and disk tests, 3.3 and 6.4 times faster respectively.

I am now completely sold on the value of the VMWare Workstation license. The best price I found after a quick search was $161. For all the saved frustration in working with a slow virtual machine development image for MOSS, the product is well worth the price. But don't take my word for it, run your own tests if you don't believe me. Of course, if you aren't running a multicore machine, and what self respecting developer isn't, you probably won't see any improvement. On the other hand, if you have at least two cores, choosing save a few bucks seems to penny wise but pound foolish!

I get a lot of forward email from friends and relatives. I've never felt compelled to do anything with any of them until, bored this evening, I read this one from my father-in-law. I don't know if any of these stories are true or not, but whether they are or aren't, they are. In a time when America seems to be taking much criticism from within and without, it's good to have reminders like these.

When in England, at a fairly large conference, Colin Powell was asked by the Archbishop of Canterbury if our plans for Iraq were just an example of empire building by George Bush. He answered by saying, 'Over the years, the United States has sent many of its fine young men and women into great peril to fight for freedom beyond our borders. The only amount of land we have ever asked for in return is enough to bury those that did not return.'

There was a conference in France where a number of international engineers were taking part, including French and American. During a break, one of the French engineers came back into the room saying 'Have you heard the latest dumb stunt Bush has done? He has sent an aircraft carrier to Indonesia to help the tsunami victims. What does he intended to do, bomb them?' A Boeing engineer stood up and replied quietly. 'Our carriers have three hospitals on board that can treat several hundred people; they are nuclear powered and can supply emergency electrical power to shore facilities; they have three cafeterias with the capacity to feed 3,000 people three meals a day, they can produce several thousand gallons of fresh water from sea water each day, and they carry half a dozen helicopters for use in transporting victims and injured to and from their flight deck. We have eleven such ships, how many does FRANCE HAVE?'

A U.S. Navy Admiral was attending a naval conference that included Admirals from the U.S., English, Canadian, Australian and French Navies. At a cocktail reception, he found himself standing with a large group of Officers that included personnel from most of those countries. Everyone was chatting away in English as they sipped their drinks but a French admiral suddenly complained that, whereas Europeans learn many languages, Americans learn only English. He then asked, 'Why is it that we always have to speak English in these conferences rather than speaking French?' Without hesitating, the American Admiral replied "maybe it's because the Brits, Canadians, Aussies and Americans arranged it so you wouldn't have to speak German.'

An elderly American gentleman of 83, arrived in Paris by plane. At French Customs, he took a few minutes to locate his passport in his carry on. 'You have been to France before, monsieur?' the customs officer asked sarcastically. The man admitted that he had been to France previously. 'Then you should know enough to have your passport ready.' The American said, 'The last time I was here, I didn't have to show it. 'Impossible. Americans always have to show your passports on arrival in France !' The American senior gave the Frenchman a long hard look. Then he quietly explained, 'Well, when I came ashore at Omaha Beach on D-Day in 1944 to help liberate this country, I couldn't find a single Frenchmen to show a passport to.'

A week after being laid off finds me wondering why I've neglected this blog. I'm currently experiencing the self recriminatory state one goes into at the end of the dead end street having recently passed the Dead End sign. Brake, execute the multi-point 180 and head back to find the turn you missed. And then realizing that the turn you missed should have been as obvious as the nose on your face.

My conscience tells me not to be too hard on myself. In one week I've had an interview or two. Have another scheduled for tomorrow. And one or two inquiries from other potential employers. Met with more than one recruiter and talked with several more. Polished the resume a bit more and started working the neglected network of friends and former coworkers--neglect as a result of me working from my home office with little real world interaction. Note to self: get out more and talk with humans face to face.

I've even taken more than one meeting from possible business partners with ideas that may or may not pan out, but I'm not taking anything off the table until I replace my mainstream income.

So if anyone needs a C# dev guy with some architecture leanings, grab my resume and give me a shout.

Sometimes the odd helper class is useful. This one might even be a decent candidate for some .NET 3.5 extension methods. These URL utilities are quite self explanatory and by no means are a complete set of URL helper methods that would be useful, but who knows, they might have something you're looking for.

using System;
using System.Collections.Generic;
using System.Text;

namespace HelperCode
{
    internal static class UrlUtils
    {
        internal static string GetTldFromUrl(string url)
        {
            string tld = UrlUtils.GetHostFromUrl(url);
            if (tld != null && tld.Contains('.'))
            {
                string[] parts = tld.Split('.');
                if (parts.Length > 0)
                {
                    tld = parts[parts.Length - 1];
                }
            }
            return tld;
        }

        internal static string GetHostFromUrl(string url)
        {
            string retval = null;
            try
            {
                Uri uri = new Uri(url);
                retval = uri.Host.ToLower();
            }
            catch
            {
                retval = null;
            }
            return retval;
        }

        internal static string GetSchemeFromUrl(string url)
        {
            string retval = null;
            try
            {
                Uri uri = new Uri(url);
                retval = uri.Scheme.ToLower();
            }
            catch
            {
                retval = null;
            }
            return retval;
        }
    }
}

If you have a better way to do it, please, by all means, let us know. There are no doubt better ways. :)

Whether it be in code or business deals, complexity kills. If you're an architect and you love the elegance of endless inheritance where everything is a descendant of MyCoolRootObject or an venture capitalist trying to tie off every risk with carefully structured language that leaves a founder in the lurch and you in the driver's seat of the getaway car, you are the enemy of success. If you flout the team's style guild and name your class members with freaky names and patterns only you can recognize, you are an enemy of success. If you're a framework developer and you believe you have to add every possible toy feature in the universe to your framework, you are an enemy of success.

And enemies of success lose! Lovers of complexity may win a battle here or there, but the ash heap of history is full of them. Consider any number of technologies that have become so overbloated and difficult to work with that developers and architects look for simpler solutions. Examine the many thousands of failed startups killed by pencil pushing pinheads with no other agenda than to make the deal difficult in hopes of making it perfect, only to kill the deal with a stulted obsession with detail and gaining the advantage in every paragraph.

Simplicity is the key to success.

I recently picked up Booch, Jacobsen and Rumbaugh's new book Object Oriented Analysis and Design with Applications. It's like the textbook I never had in the OO classes I never took. (Yeah, I'm just another self taught bozo who knows the difference between a five minute class exercise and a multiple month enterprise development project.)

Among others, I have especially enjoyed Chapter 6 called simply Process. Let me quote the opening paragraph and you'll know why.

"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists. Amateurs often want to follow cook-book steps; professionals know that such approches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsibility for earlier misguided decisions." pg.247

There's more and the book is a treasure trove of wisdom, but when I read this paragraph, it was nice to feel as if I had met the estimeed Booch, Jacobsen and Rumbaugh definition of professional software engineer.

I do remember looking for magic bullets when I first started teaching myself how to do software development. Fortunately through long trial and error and even greater opportunities to learn from true professionals, I gave up on looking for magic solutions long ago. Since then my life has been easier and busier and much more rewarding with regard to software development.

To their credit, the authors in Chapter 6 review the strengths and weaknesses of both agile and more traditional plan driven (sometimes called waterfall) process approaches. They begin their thesis in this chapter in addressing the traits of a successful project. Now having this is true magic. Here they are:

• "Existence of a strong architectural vision."
• "Application of a well managed iterative and incremental development lifecycle."

The killer qualifiers in those two statements are: "strong" and "well managed." Yikes! These are qualifications that are difficult to come by. When you do, grab them up and hold on to them for dear life. I think most of us can agree that "weak" and "poorly managed" will result in disaster every time.

In an ever more agile development world, we gradually learn to accept that requirements change constantly. Of course, it has always been thus, but I do remember a time when we pretended that requirements were locked and could not be changed. But then I remember delivering a product some months later which did not then meet the client's requirements despite what they had agreed to only months before. Their requirements changed, you see.

Now I work in an environment where this norm is the norm. Requirements change and they change often. Or better put, requirements are discovered daily and old requirements change into new requirements nearly as often. This is the unavoidable nature of the business I'm in. I accept it.

What I hate and cannot accept in this ever changing world are requirements documents written in a proprietary binary format. Sure they're stored in source control, so when I do a little update on my Subversion client in the morning and see that several requirements documents have changed, I'd like to just do a nice simple DIFF on them and see what's changed. But no. Oh, sure there are probably some diff tools out there I could get, but why should I when we could have just written the requirements in text or even a simple transformable XML rather than the binary gobbledygook in a Word or Excel file.

And can anyone tell me how to "blame" a change in a particular line in a Word doc on a certain author? Oh sure, I could use the gooey sticky messy change tracking--no thanks. Just give me a good text file and an editor that can handle it well.

Is my rant a cry for a product or what? Is there an existing product you can recommend? If so, please tell me. And then maybe we can ban the use of Word and Excel for the production and maintenance of requirements. We can say goodbye to the lack of transparency and traceability. We can say hello to simplicity and accountability. Ah, how would it be.

I'm currently working on a rather complex ETL system in the medical industry. There are new business rules uncovered daily as development and analysis proceeds in parallel due to overwhelming business urgencies. The use cases in the system are limited pretty much to "Process File." Everything else is buried in a system of business rules more complex than I care to think about very often and a series of events and event handlers which process the file and implement the business rules.

My own approach to this challenge could have been much more organized had I purchased Karl E. Weigers's book More About Software Requirements earlier on in this project. He says, "Use cases are less valuable for projects involving data warehouses, batch processes, hardware projects with embedded control software, and computationally intensive applications. In these softs of systems, the deep complexity doesn't lie in the user-system interactions. It might be might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system's behavior."

I could not agree more. Weigers goes on to recommend the use of event-response tables to provide a way of documenting the requirements of such complex systems which have little if any interaction with users. Granted, you could write a use case using the machine or file system or OS or scheduler or some other non-human entity as the actor, but the analogies break down when trying to document the requirements of the complex rules within the case.

The event-response table is a simple approach to organizing these details that in fact works much better than an ad hoc method of writing it all down in sequential paragraphs and then asking developers, in this case that developer being me, to interpret those requirements and design and code a solution that really works.

You simply need a three column table with the following headers: Event, System State, and Response.

Breaking up functional requirements in a complex rules-driven system with minimal human interaction can be a daunting task. You can make it a bit easier by using some simple organizing structures such as the event-response table.

Thanks to Miguel and his team for making it easier than ever for us Windows-bound .NET geeks to give Mono a try. It's a fairly big download but well worth it. You can now download a VMWare virtual machine image of Mono 1.2.2.1 on openSUSE 10.2 and the free VMWare Player. Install the player and open the unzipped VM file. Easy peasy. I had to play with network settings a bit but that was easy.

There is no easier way to check out Mono on Linux. No partitions to worry about. No setup to worry about. No drivers to mess with such as the constant failure I would get with my dual monitor card when I tried earlier to get SUSE running on a separate partition on my box which led to me giving up.

I recommend you give it a try. Amazing what the Mono team has done. Kudos again to Miguel and his team and all those who have contributed to the Mono project. 

There is much ado about the coming Semantic Web and the dream of objectifying all the data in the world allowing machines to exchange mindshare, yada, yada, yada. But what happens to old web pages when they die? Do they go to HTTP heaven? And when this glorious web for machines supplants the Legacy Web (that messy old WWW), what will we all do with our fancy browsers? Where will we find the fuel to power our AJAX rocket engines? And how will humans survive the rising tide of <tag><mytag>
<yourtag>hey</yourtag>
</mytag></tag> drive by taggings?

The truth is that while the semantic web will find some heavy hitters to knock it out of the park in a variety of industrial and scientific arenas, I'm not sure the messy old WWW is ready for retirement just yet. I doubt the content switch will occur very rapidly in most corners of the world given that most users of the web currently are human and they use the mundane web browser occasionally flicking the AJAX booster switch and dreaming of the connected client days of yore.

We humans like messes. Just look around your office if you don't believe me. Four out of five dentists recommend a messy desk for a healthy work life. And if you don't believe me, Google it.

Still, the semantic web bears some level of intrigue beyond its obvious usefulness in some areas of business and science. In fact, I'd love to have a browser that would help me make more sense of the mess on the WWW or even the mess on my desk.

My New Year's resolution is to explore that idea and determine whether or not it can be done in the messy old WWW world without holding a gun to the head of all those gumbah's with an HTML six shooter in their belt.

I've been busy. Yeah. Sad excuse, but true.
 
On November 7, 2006, about two months after I was hired, my employer "invited" me to resign my position because I refused to sign a mandatory arbitration agreement which among other things included the following language: "I understand that by agreeing to this binding arbitration provision, both I and [company name] give up our respective rights to a trial by jury."

I told my employer that I didn't think I should have to waive my constitutional right to petition the government for redress just because so many others abuse that right. I had researched the issue on the Internet and found that these agreements are enforced by the courts and that in about 99% of all cases, the employee loses, regardless of the issues and facts.

I was annoyed. More at the law than at my employer. I know the law stands behind employers on this issue. And I even support the idea of arbitration as a first option, but I cannot abide the idea of just waiving my right to go to court just to keep a job. I don't think the law should allow an employer to require such a concession upon employees, but it does. Specifically, as long as both parties give up the same rights, the contract is enforceable.

This would be just fine except for the fact that in arbitration, the little guy is viewed by most arbiters (usually retired judges) as the money grubbing whiner and the employer as the victim of the evil, greedy employee. So you give up the same rights but you put yourself, as an employee, at a significant disadvantage if you run into some dispute with an employer.

All that said, I've never been sued by an employer and I've never sued an employer. Still, if I had to, I'd like to preserve the option of having a real court and a real jury hear my case rather than an arbiter who answers to no one regardless of his or her conduct and decisions in the face of the evidence. Take those odds? No thanks.

I was lucky. I found another job the same day I was "asked" to leave which happily pays even better. And I've been super busy with the new gig ever since. Not everyone has the same opportunity and flexibility that I enjoy, so I recognize this development as a true blessing.

Since that day, I've spent an hour or so contacting legislators about the issue. They are generally either indifferent or completely ignorant or in some cases both. Senator Hatch sent me a nice, completely off-base form letter reply referring me to legal counsel despite the fact that I had just asked for his opinion on whether employers should be allowed to continue this practice and whether he would support legislation to prohibit it. Many others just never responded. It's pretty sad when elected officials care so little about the way that employers are now forcing their employees to give up their constitutionally protected rights just because they are afraid of employees who abuse those rights.

It's typical fare for our culture. Punish those who have done nothing wrong in the false hope of protecting yourself from the real bad guys. Similar examples are not difficult to find. Such draconian practices are not needed. If you're going to get sued by employees, you're going to get sued. And if it happens a lot, you might want to consider changing your behavior and/or changing who and how you hire.

If you're reading this and you've signed employment documents without really reading them, you may have signed a similar document. I recommend reading every document your employer "invites" you to sign. Despite your excitement to have a new job and your high opinion of the people you'll be working for, you may be surprised at what they've asked you to agree to. There's only one way out of such an agreement. Don't sign it in the first place. I really liked the people at the former job, but regardless of my regard for them, I was not about to give up my rights in order to work for them.

Of course, everything I've said here is my own opinion. I'm sure my former employer sees it completely differently. I bear them no ill will and certainly have no plans to waste time and energy on the lawsuit that so many of my friends have recommended that I bring against them. I would just hope that they would see their actions for the paranoia I believe it to be and revise their agreements with their existing employees. I think it would be the right and moral thing to do. But that's up to them.

With that all said, I'll get back to coding and promise some real .NET coding posts here in the future.

Thanks to Google CoOp, www.netbrick.net is now my personal .NET developer search engine. With the help of a few friends, the list of domains searched remains relevant to .NET development. This helps eliminate all the clutter I get when hitting Google directly.

Thanks to Paul Allen for alerting me to this very cool feature. And if you use it, don't be afraid to click on the ads. :)

Today I attended my first UCNUG meeting. It was great. Easy location. Perfect size crowd. Great presentation by Aaron Zupancic on refactoring.

Previous meetings have been held at UVSC, but fortunately they got kicked out of there. I'm lazy by nature and didn't want to bother with finding the room on a campus I don't know. This one was hosted gratiously by NuSkin at the East Bay location and that was easy to find.

Aaron gave a well thought out, cogent presentation on the ins and outs of refactoring. I actually learned some things. And for me, that makes any presentation valuable. But it was a good presentation as much for what Aaron did not do as what he did do. He did not just read from the book. Martin Fowler is great but the presentation was really valuable because Aaron pulled examples and ideas into slides with even better code examples.

I've attended the Utah .NET Users Group, where Aaron is the president, a few times. The presentations are generally good, including Aaron's, but this one was much better. I'm trying to convice a buddy of mine to present on CruiseControl.Net, NUnit and automated build and testing in general. I'll post it here if I can get him to commit.

Installed IE7 (7.0.5730.11) over the top of the beta. Everything working well so far. Ah, but now, because of the increasing clutter on my drive, I'm running out of space and will soon be rebuilding my machine. Just another chance to install, install, install.

Point, click, wait. Repeat.

It's been less than a week and my www.photohistorydoc.com site has caught up by many RegNow affiliates, hacked by some warez hackers in the UK, Israel, and Australia, and indexed by Google. The question I have is why does Google continue to index warez sites whose primary purpose is to sabotage the shareware and commercial software industry.

So, Google, why? Why do you help promote these low lifes whose only goal seems to be to troll for software thieves susceptible to the enticements of porn in order to make money from the click flips to the real porn sites. Why? These sites don't use AdSense, so there does not seem to be a monetary motive. What else can it be?

Does anyone have a clue?

After two months of working nights and weekends, I've finally finished Photo History Doc, my little contribution to the shareware world. I'd love to hear what you think about it. Visit http://www.photohistorydoc.com and download it and let me know what you think.

I'll post more about it and how it gets received out in the world later.

I'm disabling trackback on my blog because one particular post gets spammed with about 30 porn trackback spams a week. All of them in one batch. They point to seemingly empty places. So if you want to trackback here, sorry, too bad. It's too much of a pain to delete all the spam trackbacks and there is no easy way to track the offender or block him/her/it.

I want a T-shirt with these words on it:

Bad Code is Platform Independent

All the political and religious debates about platform superiority all come to an end when running bad code. It amazes me how much bad code is out there (some of mine included). And yet we so often jump to blame the platform, runtime, operating system, tools, or some other outside element.

Where have all the good coders gone? More to the point. Were there ever any?

Bad coders never die, they just pick a new platform.

Nothing like a great laugh to perk up your day. Stumbled onto this Captain Zilog on computerhistory.org today. Take a moment and read it. What happened to those good old days? Did the dolldrums of reality take over?

"Systems designer Nick Stacey works late into the night, unknown to him, a small eerie comet passes overhead..."

"I am known to men as...opportunity! I give you the key to man's destiny in a brave new world!"

"It is the beginning of a new freedom for man's imagination! It is a microprocessor! I bestow upon you all of the knowledge that goes with it, but use it wisely! Now, go!"

Corny? Yes. Prescient? Definitely. It was 1979. I was in junior high school. It was the battle of the little, inventive, hungry geek vs. the titans of business with deeper pockets than I could imagine. It was an epoc battle that went to the best and the brightest, not to the most powerful. Or so it seemed. But as a kid, I was only barely aware of the war that raged in the world of technology in those days. To me, it was just an exciting time of change.

Now, change is more terrifying because I have responsibilities. I have four kids, a mortgage and car payments. Just like everybody else I know. And a lot has changed in the last couple of months. And it's been terrifying. And exciting. Two days ago, I blogged about the ethics of meta-searching. It came as a shock to others involved in the project because I had not discussed it with them. I blindsided them. That was fundamentally unfair. And yet, even had I wrung my hands over the issue and discussed it with them, it would probably not have changed the end result. Things changed. And it scared the heck out me. Some of them are probably still angry with me. I don't blame them. I would be too.

Looking back to the days of Captain Zilog made me laugh. It also made me think. Zilog is not a player in the huge PC market. But it's still alive and from all appearances, it's doing well. They innovated. They struggled. They stayed alive and ultimately found a niche market that has served them well. Are they comparable to giants like Intel and Microsoft? No way. But did they survive? Did they make money. I'm guessing that they must have given the fact that they're still around and still selling the Z8 line.

So what is our challenge? We must find a way to survive. Find a way to innovate something truly useful. Believe in that thing. Work hard to make that thing succeed, even if it's in a market you had not originally foreseen. In other words, we must adapt without losing a sense of who we are or what we've created. Time will tell if we, as technologists and entrepreneurs will do just that.

(Modified slightly on Monday, August 21, 2006, after considering issues of fairness and further introspection.)

For the first seven months of this year I worked on a project which, in part, was a meta-search tool designed to bypass the router pacing algorithms used by sites such as Google, Yahoo and MSN. I have come to believe that even if this were not a violation of their terms of use, it would be fundamentally unethical. I cannot claim the high road in having come to this conclusion. I did not arrive at this conclusion until some time after becoming unemployed and then re-employed.

Yesterday I began to question myself more seriously about the ethics of meta-searching than I had done before. Without doing any online research, a rarity for me, I just wrote down in long hand some basic questions and let one lead to another. My conclusion was that I could not ethically or morally justify the acquisition of data and resale of it in some form or another using meta-search techniques in violation of the source's terms of use.

On July 21, 2006, I was suddenly unemployed along with the rest of the development team at Provo Labs LLC, a Paul Allen (the lesser) venture. I didn't abandon the project even then. I looked for ways to keep the project alive. After all, I had spent months, including nearly every Saturday and Sunday, working on the code for this project. It was my baby. I was the only developer on it. A week or so after that fateful day in July, reality set in. I had no income and four children to feed. I had to find a job. And I did. A great job! The timing could not have been better.

In my first three days on the new job, I was impressed by the effort and expense the company is willing to expend to be sure that copyrighted material used in their product is properly licensed. This reminded me of a conversation I had had with management at Provo Labs earlier in the year. I had raised the question of the ethics of meta-searching and collecting data using automation from public search engines and other resources whose terms of use statements clearly prohibit such behavior. The discussion was brief and the subject was quickly swept aside. It boiled down to "everybody does it, including the search engines, so that makes it okay". I filed that rationalization away and kept going.

The intellectual property transfer from Provo Labs LLC to the new company Phil Burns is starting had not yet happened. I had even contemplated using my company, NetBrick Inc, an S corp of which I am the sole shareholder, as a holding company for this new venture. But I had become impatient and as Phil put it, "emotional and panicky".

I had my doubts about the whole deal and so today I pulled myself out of the deal entirely in part because I had lost faith that we would successfully negotiate the intellectual property rights to this product, in part because I did not believe I would have time to continue working on the project, but mostly because I had come to believe that it would simply be the wrong thing to do.

This process of introspection has been painful. I had to admit to myself that for the last seven months of my life, I have been building, enthusiastically, a product that was in large measure designed to violate the terms of use and possibly violate the law in the acquisition of meta-data from search engines and other sites for the express purpose of reselling that data in the form of market research and other such reports. I had rationalized this by thinking that we would not sell the data but only the conclusions we reached from the data. Splitting hairs like this was just another way to sweep the ethical inconsistency under the rug.

Today I informed Phil and Paul that I will no longer be involved with the project as it stands and that I will deliver the code in its existing form. I did not share with them my reasoning behind my decision because I really did not want to engage them in a debate on the merits of my decision. We had already been down that road.

After I informed Phil and Paul by email, I did some online research--something I really should have done, and unbelievably did not ever do, prior to starting the project. From any of the big three engines (Google, Yahoo, and MSN), you can click one or two links to get to the following terms of service information.

Google
http://www.google.com/intl/en/terms_of_service.html
"The Google Services are made available for your personal, non-commercial use only. You may not use the Google Services to sell a product or service, or to increase traffic to your Web site for commercial reasons... You may not take the results from a Google search and reformat and display them... You may not "meta-search" Google... You may not send automated queries of any sort to Google's system without express permission in advance from Google. Note that "sending automated queries" includes, among other things: using any software which sends queries to Google to determine how a website or webpage "ranks" on Google for various queries;
"meta-searching" Google; and performing "offline" searches on Google.

MSN
http://tou.live.com/en-us/
"In using the service, you may not:...use any automated process or service to access and/or use the service (such as a BOT, a spider, periodic caching of information stored by Microsoft, or “meta-searching”);"

Yahoo & Overture
http://docs.yahoo.com/info/terms/
"Except as expressly authorized by Yahoo! or advertisers, you agree not to modify, rent, lease, loan, sell, distribute or create derivative works based on the Service or the Software, in whole or in part."

Clearly, these search engines do not want you to use automated search software to mine their meta-data presented in search results and the results of other search related queries. It is clear that their intent is to only allow individual users through a normal web browser to access and use this information. Yahoo is more vague than the other two but the intent is still there.

So is the search engine behavior of crawling the content and indexing the content of other web sites unethical or immoral? Does that violate the terms of use posted by many other sites? Will the search engines remove your content from their site if you request it? I do not believe that it is unethical or immoral to drive traffic to a web site because its content contains what a search engine user probably wants to find. The search engine is not repackaging and reselling the data they find on the crawled sites. Yet they do profit in some measure from mining that content, for without the content, they would have no users. It seems to be a trade that most web site owners are willing to make.

I want to make it clear here and now that I believe that if I had made my concerns known to Provo Labs management more forcefully in the early days of this project, they would not have required me to work on it. They would have, I think, found something else for me to do. I hope this illustrates the flaw in my own character, which I hope to remedy in this, and does not leave the reader of this post to believe that Provo Labs LLC acted in an unethical manner.

The code is powerful and capable of being extended and used in a variety of ways. A friend of mine pointed out to me that not everything it does is a violation of terms of use document. In fact there is a lot of things that it is designed to do which goes no further than a typical web crawler in terms of gathering data. Perhaps a means can be found to make use of what it can do without violating terms of use policies. Perhaps the power of the code can be leveraged within the framework of licensed APIs. This is something that will have be determined.

Until that time, I'll continue my work at my new job and focus my personal coding efforts on my Forseti Project to keep my coding skills as sharp as I can. And I will take away an important lesson from this whole roller coaster ride: always examine and question the ethics of a project and then listen to your instincts.

If you'd like to comment and berate me here, go right ahead. I deserve it. If you're particularly vicious, I reserve the right to edit or remove the comment. If you've had similar experiences and stood up more valiantly, I'd like to hear about it and how it all turned out for you.

Just found this referenced on an FTPOnline story: http://www.turboexplorer.com/

For an old Delphi aficionado (version 5 was my last), I can't wait to download the Explorer versions to see what they've done with the place.

I've always felt that starting with a Borland tool was a better place for a beginner to start. And then you take a corporate job and everyone is drinking the blue coolaid. Don't get me wrong. I like the coolaid too. Visual Studio 2005 is hands down the best IDE I've worked with. And no, for you Eclipse fans, I've not tried that highly vaunted IDE. I do know people that have used both and they invariably have good things to say about both.

Borland is spinning off the tools, so they say. So where will they be spun and how do these new dolled up Turbo versions fit into the equation. And so I don't have to wait so long, is there anyone at Borland that can get me a sneak peek copy.

I promise to run it through it's paces and report back here. I'm especially eager to try the C++ flavor. Could the good old days of Turbo be back? Let's see....

SOAP vs REST
In my work I've had occassion to use both SOAP and REST in the client and the server. SOAP is easy if you have good tools. Hard wiring a WSDL is not my thing. At the risk of committing a pun foul, I'd rather eat a bar of soap than hard code good WSDL. Fortunately, .NET makes WSDL for simple web services easy, both on the server and client end of things. And WSCF makes more complex web services easy in the .NET world.

At the same time, REST is more comfortable, especially for those without nice support tools for consuming SOAP on a plate of WSDL. A nice simple HTTP POST. A simple agreement between friends to pass X, Y, and Z data along in a simple name value pair model.

Trust or Verify
I guess in some ways it comes down to trust. Do you trust the client to submit clean data? Can you trust your server application to parse through and make safe any data that is not clean? Or would you rather automate some of that authentication via schema and the rigidity of SOAP? For me, it all depends on the circumstances.

The Illusion of SOAP and Schema
How tight are your contracts? A good lawyer will take a two page agreement and expand it to ninety pages. Not only because she wants to bill you more but because she needs to cover all the bases. Are your web service contract bases covered? Is the schema and secondary validation sufficient.

Can REST Be Secure?
This line of thought takes me to the question. Can we trust REST? Well, the short answer is no. But the longer answer is, yes, just as much as we trust SOAP. The brilliance of SOAP is the contract is carried with the data, or at least that data is transported in a container with which the contract may be validated. So is that really better? Well, the underlying truth is that someone else wrote a bunch of helper code to help us perform the first level of validation in the message--form. But what about content. Yes, schema validation can do some content validation as well, especially of the type type of validation. Beyond that, it's up to you pretty much.

Validation Bottom Line
Ultimately the value and robustness of a web service, whether you use REST for it's simplicity or SOAP for the niceties of automated tools, will be determined by the code you write to validate and execute and respond with an appropriately formed response.

Consider Your Audience
Back in my poor old days as a technical writer, I had to always keep in mind and understand my audience. It really does matter. For example, my mother would not understand a single word of this post. If you are publishing web services, you must consider who will consume them. Will they be a hodge podge of PHP, JSP, ASP, and many other forms of "server pages" technology? Or will they be hard driving Visual Studio SOAP users who would rather have the tool do the heavy lifting and eliminate the need to parse?

Give your users what they want. And to do that, you may have to give them both SOAP and REST. I guess that won't hurt us too much. After all, a hot shower is always a good combination with a good night's rest.

A friend shared this Joel on Software post with me today. An absolute hilarious read.

Excerpt:

"So you don't have any hammers? None at all?"

"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."

"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"

"Yes."

Frameworks have their place but time seems to be unkind to them. I'm not a Java guy but even the Java zealots I knew "back in the day" are now less bullish on the frameworks mess that exists on the Java stack. And no, for you remaining zealots, I don't want to fight about the point.

The fact is, the .NET Framework is only a few years behind. Will it bloat too? Has it already started with 2.0 and all the changes in ASP.NET and so forth and so on? Will 3.0 see bloat or a cohesive, more conservative growth pattern.

If we're all doomed to framework elephantitus, what is the solution? My hope is that Microsoft will learn from the failures of its biggest competitor and work as hard to keep the framework tight as they work to sell their operating systems. The same aggressive and successful behavior will be the only thing, perhaps, that can save us all from the same doom suffered by our Java brethren who are now escaping in droves to PHP.

Okay, I made that last part up. But it could be true.

I"m not a marketing guru. Never have been. Never will be. You too? So how do we maximize traffic to our blog, our side project, or our main gig? Well, we tell our clients to hire us, the expert, when they need some coding done.

So hire an expert.

I know just the expert. I've watched these guys in action. They know what they're doing. Check them out at http://www.webevident.com/ppc-management.php.

They can handle all your pay per click campaigns. And you would be surprised how much traffic they can drive to your site on a very tight budget. They do a free analysis for you, so you have nothing to lose by at least checking them out.  

My wife won the lottery. Two hundred thousand dollars. Uncle Sam took half. She said, "I want a new car. Go buy me a new car."

So I took the checkbook and bought a brand new Honda Accord for $30,000. When I arrived home my wife said, "I didn't want an Accord. I want an SUV."

On the way back to the dealership, an accident occurred. I escaped with my life but the car was a total loss.

I still had the checkbook so I wrote a check for $40,000 and took home a nice, new Dodge Durango. I was so pleased with myself.

But my wife was not. She said, "The Durango is too small and I don't like the color red."

So I turned around and took it back to the dealer. I asked for my money back but he whipped out the magnifying glass and pointed out the small print: "absolutely, under no circumstances can you get a refund."

"Besides," said the salesmanager, "we've already spent the money and we can't take a new car in trade. It's just policy."

So I drove the Durango to the Ford dealership and on the way was rearended by a large truck. The Ford dealership gave me $10,000 in trade and I wrote a check for $40,000 more for the last of the new Ford Excursions.

I drove the Excursion home. Finally my wife was happy. "Now let's go buy the boat," she said.

"Sorry, honey," I said. "We're out of money."

So we have this giant SUV and we can't afford to put gas in it, and we have nothing to pull behind it.

But, we do have an SUV that cost $100,000 and in three years will be worth less than $20,000. And as a compensating note, I can haul a ton of groceries with it which helps save the cost of gasoline to get to the grocery store in the first place.

Now if only we could find another lottery to win.

Well, after struggling to get Fedora 5 to run on my machine and get the GUI up and running on an nVidia card, I've given up on this distribution after finding this bit of nasty news.

I think I'll try SUSE next. I've tried using the "YUM" updater and following a variety of instructions from a variety of posts to get my dual monitor eVGA GForce 7800 GT to work. All to no avail.

Once downloaded and installed, I'll post the results of my attempts with SUSE 10.

I've begun the journey into Mono. Fedora 5 is nearly completely downloaded. I've freed up a partition on which to install it. I've downloaded the mono-1.1.1.13.6_0-installer.bin from the official site.

Why?

Because I'm building a system that must scale to many machines and we're considering using a virtual machine hosting system. And they only host virtual Linux boxes.

Will we definitely host the application on virtual system? No, not definitely. But if the port to Mono goes well, it's certainly an option.

My concerns about going to Mono is first, I know very little about Linux. Second, I'm using System.ServiceProcess.ServiceBase for my server, and that namespace, as far as I can tell, is not supported in Mono. So these two items may pose a bit of a learning curve.

After downloading some but not all of the Mono source files, I began wandering about and looking at how the Mono team has implemented various class libraries that we .NET developers take for granted every day. Talk about a wealth of code samples that will be extremely valuable in my daily work, regardless of whether I'm in Mono or MS .NET coding.

I'll post more on my progress into the world of Mono and Linux in the future. In the meantime, if you have any words of wisdom for me, please feel free...

I very much enjoyed Dion's Thinking in Web 2.0 post. The ways to think in Web 2.0 seem to be growing with significant and useful comments. I would like to propose a side discussion that attempts to reduce Web 2.0 to seven specific principles.

The Highly Effective Web 2.0 is:

1. Specific - Purpose, content and interface is quickly understood.
2. Standard - Data is offered via open standards and protocols (i.e. HTML, XHTML, SOAP, RSS, SSL).
3. Transparent - Privacy and other policies are enforced and simple (see #1).
4. Accessible - Data should be easily found for those with and without disabilities.
5. Interactive - Participation is be encouraged and facilitated (see #1).
6. Inclusive - One thing leads to more like things rather than fewer.
7. Evolutionary - Everything is both familiar and new.

I tend to be overly verbose while clinging to the principle and value of brevity. If we are to understand the Web 2.0 wave, perhaps we can reduce it to seven (no more) principles that are stated simply and without the need for great expansion despite the fact that books may be written on the subject.

Please comment. Let me know which one(s) you would replace, with what, and why.