I Need A New Phone

My friend has a cool Nokia with a 3 or 4 megapixel camera and it just puts my Dash to shame. Which means that now I'm in the market for a new phone.

Here are some things I care about in weighted order of importance:

1. 3+ megapixels
2. autofocus
3. windows mobile 5+
4. works on t-mobile
72. standard headphone jack
74. sd card slot
81. flash
89. gps

So any ideas?

Right now I am considering the HTC Touch Cruise and the HTC TyTN II. But I'd love to find some more options to choose from. Surely there are other choices?

Outlook 2007 on Vista accessing Exchange using HTTP over RPC

If that title didn't mean anything to you, ignore this post. (Well, you can click an advert on the right first! ;-)

Just recently I've updated my laptop to the latest Windows operating system release named Vista. Since I'm out in the field, I don't have a nice persistent connection to my corporate network and Exchange mailbox. After installing Office 2007 (which I'd been using for some time and can say is quite good!) I needed to get my email configured again. So I point and clicked everything as it was configured before. Alas, no joy.

After researching a bit online including a very poorly worded and far too succinct KB article (found here), I got it running again. I've listed the important steps below, skip them at your peril.

1. Open regedit or your other favorite registry editing tool.
   If this is unfamiliar go get your geeky computer friend to help. You can really screw things up playing in the registry, so only do this if you know what you are about.
   
   
2. Locate the following subkey:
   HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC
   You might not have the RPC portion of the key. I didn't. Just create it if missing.
   
   
3. Add a new DWORD value named DefConnectOpts with a value of 0.
   You have to get the name correct, and make sure the value is set to zero.
   
   
4. Restart your machine.
   This is usually the first step I skip. You can't do it this time. It won't take effect until restart. There probably is a service or .dll that can just be unloaded, but what a hassle. Keep it simple and just reboot.
   
   
5. Delete the profile you had, and recreate it with valid settings.
   At this point it should let you login to your Exchange server via RPC over HTTP. If it didn't you probably skipped a step or hit that special "you're screwed" portion of code. Call your techie friend.
   
   

My default Vista install did not have the RPC portion of the above key. So, I just created the key, then added the new value. I first deleted the old profile, then rebooted the computer. I created a new profile and it worked. Your mileage may vary.

3 Pass Coding

Back in the day at Microsoft we used to look for and train developers who were 1 pass coders. In today's world everyone is a 3 pass coder and they are starting to drag me down with them.

Let me explain the difference between a 1 pass and a 3 pass coder.

When you are writing code there are several layers (or aspects) of design and implementation activity that have to be balanced. Firstly, you have the very simple, but often disputed, question of whether the code will meet a functional objective. This is often referred to Working. If the code won't perform the purpose the code is intended for it Doesn't Work and the rest of its qualities aren't relevant. Assuming that it can be made to fulfill its intended purpose (i.e. it Works), then the other two aspects suddenly become important.

The next most tangible aspect of coding is the speed at which the code will execute or process units of work, transactions, operations, etc. Regardless of the velocity or metrics implied, the measure of this aspect of coding is generally called Performance. Making something Work is the first step which is immediately followed by does it Work Fast.

Lastly you have a host of intangibles of varying degrees of importance. There can be many tangible expressions of these intangible attributes used by different people at different times. The number of comments, the readability of the control flow, the robustness of the error and state management, and the lack of logic or bounding bugs; are all examples and all of which are related. We put these closely-coupled items in a big bucket called Quality. This may also referred to as Maintainability, Elegance, etc. If you can make it Work, and make it Work Fast, can you make it Work Correctly?

Now when someone starts out coding, they generally are capable of keeping only one layer in their mind at a time. They start by making the code Work. They just want to see it do what they think it should do. Of course, once it does that, then they immediately concern themselves with making it Work Fast. It is about this time that consumers of their code start exercising the possibilities and uncovering flaws and boundaries of the code. So a review of code usually focused on specific bugs or concerns is undertaken until eventually it is determined the code must Work Correctly. This lifecycle usually involves 3 distinct reviews or Passes on the code. It is written, then reviewed for performance or capacity, then again for bugs and boundaries.

On the other hand, a 1 Pass coder will have such a clear picture in mind of the code, the control of flow, the logic loops, the impediments and enhancements to speed, the boundary conditions and bug potentials, that the exercise is compressed into a single Pass of coding. All the work is done upfront in the design and in the construction of each line so that intangibles are caught during the initial pass.

At least that's how we used to do it. It's how I used to do it.

Now engineers are so woefully under-skilled. They aren't forced to learn logic or bit math. They didn't take any classes on algorithm design or perform exercises on bug potentials. They just want to see it Work and then have testers tell them what else needs fixing. If you want it to Work Fast they just buy bigger boxes or more of them. The days of discipline are gone.

When I have to oversee their work or explain an implementation I find myself being forced to speak in terms of what it takes to make it Work because the other layers trip them up. If I show them tight, elegant code with robust error and state management and efficient control of flow, they can't read or follow it. When I assign bugs they want to debug and watch the code execute because they can't find the bugs by reading the code. I have to worry about losing my own skills just working alongside them.

Yesterday for a personal coding project I came across a bug running the program and my first thought was to set a breakpoint and see what happened. I wanted to slap myself out of the chair! I'm better than that. I can READ and understand code. Which doesn't mean I don't take advantage of the debugger, but it shouldn't be my first thought. I'm a 1 Pass coder and I intend to stay that way.

Eventual Correctness

Have you ever heard the term Directional Correctness or perhaps Directionally Correct? In the software business it is often used for when the concepts, functionality or usefulness of a thing is understood or apparent, even when there are details or bugs that prohibit full acceptance.

If you are building a form for the user to input data, having all the form elements and the submit button without any formatting, style, or validation would be considered Directionally Correct.

The process of building something new is often littered with the broken attempts and failed assertions. This is actually one of the driving motivations between Test Driven Development. Good designers use iterative processes to arrive at a great solution, it doesn't just magically appear. Great designers help those around them iterate also.

Have you ever looked back at the end of the day and realized you worked on the same design element the entire day? Have you ever had a user or consumer completely yank the carpet out from under you and realize that all the progress you made wasn't progress at all? A key reason this occurs is because we get too focused on the details too soon in the game. After all, the greatest engineers are perfectionists. It isn't done until it's Right. And that is what trips us up.

As engineers and designers we should foster or sense of elegance and perfection. Just not right away. We need to evolve our solutions, not magically produce them instantly. Produce something ambiguous and generic but somewhat functional. Or at least demonstrative of functionality. Get the users and consumers hand-waving in the general direction. Once you've achieved some agreement on the direction you are taking, then you can start hammering in nails and confirming details.

Besides being able to verify your work with consumers, it is important to delay details for your own benefit as well. The old Forest vs. Trees problems can impact even the most seasoned woodsman. As you implement your vision the details will reveal themselves. The gaps and holes will become obvious and you can address them with precision and prejudice. If you focus on details only after you have verified your directional correctness, they won't move or shift so you can be certain your specific solutions will serve.

It can be hard to iterate, especially with our innate desire for perfection. Iteration is like delayed gratification. You can make it perfect, it will be amazing and elegant. . .eventually.

Absorbing Change

Embracing change is something at which I am usually very adept.

Some might even say that is because I am responsible for most of the change that I see around me. At least on projects. But that isn't fair. I recognize as well as anyone the necessity to stabilize from time to time. To slow the pace at which change is being identified and absorbed into an organization. Many of the processes and much of the effort I exert is designed specifically to assist with the absorption of change; controlling the velocity that change impacts ongoing efforts.

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.
-- Martin Fowler

Sometimes large changes are required. It is natural for individual contributors to get invested in their work and become very attached to their specific deliverables or designs. To my mind, being flexible is a critical component of competence. Without adaptability, your useful as a contributor is minimized and in some cases suspect.

Going beyond the ability to handle change as someone customer-facing is the capability to influence both the speed at which change is introduced to the delivery organization and the expectations of the customers creating that change.

To be a good lead, protect the pace of change you expect from your people. To be a good consultant, manage expectations with your clients about the changes they want to introduce.

Dead Man Walking

Most software projects fail. The statistics are varied but a pretty fair sweeping generalization of all the research would indicate that most software projects fail.

If most of them fail, then it is logical to surmise that at any point you care to examine them, the majority will be dying. Sure, they might hang on. They might be fighting horribly and even look like they have a chance to succeed. But most of them fail. They die.

If you were out hiking in the woods and came upon a man mauled by a bear and he was shouting incomprehensibly and swearing like a sailor what would be your reaction? A helpful or trained person might run over and assess the situation. They would question and listen, they might possibly poke or prod. The answers might be meaningful or simply swearing or more realistically just Pain, Pain, Pain! The conversation would get more succinct, more direct. Answer me or I can't help you! Neither would stop to criticize poor grammar or discuss the appropriateness of language. They would listen to the content and contribute to the sharing of information. Presumably, they both want to save the dying man.

As the situation progresses, the person trying to assist the dying man would make decisions based on what they independently observe is hurting, by which movement brings the loudest screams, or by which open wound is bleeding most profusely. Because the priority of the situation demands it, they would ignore the swearing and the sweat and the blood. If the wounded soul gets out of control, they might sedate them if possible, or simply slap them to snap them back to reality and focus. Having been in similar situations, I can tell you there is shouting and flailing galore. The communication will be rough, it will be high velocity, and it will rarely be diplomatic or couched in rhetoric and hyperbole. After all, someone is dying.

If you are starting a new project, chances are it is already dying. Will you watch politely while it bleeds out? Will you bind the hands of those who can set the bones or knit the flesh? When a person with their hands in the gaping head wound says "Move!", don't demand they say Please. Remember, your project is dying.

We Have a Piper Down!

Yesterday I was attempting to customize my Flickr feed so that my Twitter posts would be more readable and I used Yahoo! Pipes to make it all happen.

The above buzzword-laden sentence is an example of flurry of intertwined concepts and technology that is rapidly becoming a cornerstone of my life. And I love it!

Yahoo! Pipes is very cool technology. A stunning example of driving adoption through value-added services that are intangibly monetized. (What a friggin' mouthful.) What I mean by that is that Yahoo! Is providing this service free of cost and what they are realizing is a slew of benefits that don't have direct immediate financial gains. The long-term gains of developer loyalty and driving adoption of their related services (Security, Mail, Blog, Reader, Calendar, etc.) will pay off in spades if they continue this trend.

During the early years of Windows there was the Win32 War. Some people thought 16-bit processing was better, others wanted 32-bit. Apple as a platform or Windows or OS2 or ? It became apparent that the way to win platform adoption was by having the most applications for that platform. You get the most applications by making it as easy as possible for developers to create those applications. This is the same today when the "platform" is a service you want used, and the "developer" is a consumer who points and clicks and publishes feeds.

The thing I found most intriguing about the Yahoo! Pipes offering is how easy they've made it to leverage all the outstanding work that others have created. Not only is there a massive wealth of capabilities directly in the tool, but the ability to clone other Pipes means the learning curve and information sharing is ridiculously easy. Whoever is running the show over there needs a serious raise, and a bigger budget. More of this and better press would put Yahoo! as a platform much more seriously in the running.

Don't Get Bullied

Building software for a crowd of generic consumers while challenging, operates by some reasonably straightforward rules that can be reasonably understood. For example, simpler is better.

On the other hand, building custom software for an educated user-base to fulfill specialized processing is excruciating because of the unreasonableness of it all.

The closer your users are to the problem, the more ideas they will have on HOW to solve the problem. This naturally leads to a slew of fragmented and disjointed concepts as they attempt to articulate in fits and starts their individual, informed, ideas about how the system should function.

At the other end of the spectrum, having educated and empowered users who will discourse with you about the nature of the problems to be solved, listening with open-minds to potential solutions, providing feedback to perfect the product, this can be hyper-productive.

We like to say, "They know enough to be dangerous."

When you have fragmented and disjoint components that don't subscribe to a cohesive approach to problem resolution you end up with lots of superfluous code that is usually much more complicated then it needs to be. Twice as much code doesn't make the solution twice as complex, more code adds exponential complexity.

This is not to say that you altering the end-goal for the functionality being delivered, you are changing HOW the software will meet the end-goal of functionality. When you subscribe to a cohesive vision, the product isn't just easier to create, it is simpler to test, quicker to validate, more robust in operation, faster to debug, and much easier for a user to adopt. The evidence supporting this is vast and varied across the technology landscape. The simpler answers always have broader adoption.

When you approaching an engagement, ask yourself what kind of user-base is supporting your efforts. Are they generic and uninformed? Keep it simple. Are they educated, pushy, and sure of their solution? Good luck with that (unless you can change the game). Are they empowered but open? Engage them early and often and you'll be really successful.

Is That Your Hand In My Pocket?

Yesterday we heard from our own news sources about a recent release from the US Justice Department about allowing fees for priority routing of internet traffic. Today, courtesy of the BBC, we see a simple restatement.

The US Justice Department has said that internet service providers should be allowed to charge for priority traffic.

The agency said it was opposed to "network neutrality", the idea that all data on the net is treated equally.
-- BBC News

Why can't our news ever spell anything out this simply?

What’s next? An Uber-Elite Network that’s much faster than the current one…oh wait, we already have I2…
Well how about a private network that you have to pay for higher bandwidth…oh wait, all the major carriers already do that…

Hmm…something is fishy about this, I just can’t quite put my finger on it.

Come On, Jump On

Big projects are great.

Okay, I work in consulting so that seems a little obvious. But hear me out. Big projects aren't just excellent because they usually mean big money. They are also great because of all the intangible benefits and unaccounted for side-effects.

When people are working on big projects, the little inefficiencies and mistakes they are used to compensating for become exaggerated and glaringly obvious. Likewise, those who can really deliver get an opportunity to do so on scale that is unmistakable. Your performance or lack of it is much easier to identify when the magnifying glass that is a large project is applied to it.

Of course, it isn't just personal performance. The demands of your clients, the companies you work with, the policies you have in place for growing people. All these are put under the stress of longer durations, more bodies, and a much wider diversity of insanity.

The meta-lesson for me here is; if you, like me, have the tenacity to jump onto the back of a moving band-wagon then it seems polite to let the guys at the front do the driving.
-- David Ing (From 9 till 2)

One cool thing I really have come to really appreciate is how the gravity well of a big project showcases the motivations, self-sufficiencies, and sometimes even the loyalties of those you work with regularly.

Let's face it, steering a titanic is hard. Really frickin' hard. If it is for only a short time, or when the penalties are small, you can overlook lots of sniping, counter-productive, or selfish behavior. Start stretching the durations or increasing the costs of failure, and watch how the spotlight finds those who act counter to the culture or the company.

The Traits You Can't Fake

From project to project and company to company, the question about how to find great resources, how to interview well and weed the gems from the rough has consistently arisen. This problem is closely related to the situation faced when trying to figure out who to reward and how to measure contributions for individuals in vastly different roles or environments.

Whether evaluating a candidate for a potential fit or comparing two very different but competent engineers, I have found there are two traits that help me separate the wheat and the chaff.

I prefer the folly of enthusiasm to the indifference of wisdom.
-- Anatole France

First off, you can't fake enthusiasm. There is simply no substitute for the intangible value that enthusiasm supplies. Someone who is consistently happy and has only average ability is worth far more than someone who is very skilled but always grumpy or disgruntled.

If you are not fired with enthusiasm, you will be fired with enthusiasm.
-- Vince Lombardi

Ask yourself if you trust that they'll get things done if (and when) you leave them alone. Find out if they're looking to get on your specific bus, or if they are just looking for a ride, any ride. Make sure they can demonstrate passion for both positive and negative things around them. Even the most staid among us can get passionate about things we love or enjoy. But if they are broadly accepting of all annoyances, they probably aren't going to be very creative about working efficiently. If they won't talk about the little things that bother and motivate them, they probably lack that insistence on quality that true performers must have. Likewise, they should be able to articulate why the things they enjoy are enjoyable! If you can't get pin them on both extremes, rest assured their work product won't be either.

Creativity is a natural extension of our enthusiasm.
-- Earl Nightingale

The second trait is a follow on to the beauty of passion: inquisitiveness. Given opportunity, do they ask lots of questions? People with passion want to understand problems and propose improvements. The natural state of an evolving mind is to be filled with questions. Smart people, experienced people, know that questions are an imperative prerequisite to understanding. If they don't want to ask questions, they aren't really seeking to understand.

Curiosity is, in great and generous minds, the first passion and the last.
-- Samuel Johnson

When you observe how someone questions, you see how their mind works. You see the speed with which they assimilate and incorporate new information. You often will see the clues to their biases in the solutions they espouse; you can see how disciplined they are by how they stay on focus or by how rigorously they apply new vocabulary. When questions don't have answers or answers that are incomplete, you can glimpse how they handle frustration, disappointment, and even their own ignorance. One of the quickest and surest ways to gather insight into the mind of another is to watch them learn something new.

Curiosity is idle only to those who fail to realize that it may be a very rare and indispensable thing.
-- James Harvey Robinson

Call me...ScrumMaster

So evidently know I'm a Certified ScrumMaster. Yay.

You have to attend a two-day course, which if you are lucky like I am, will be with your friends. During the course, you get to practice your Scrum skills and take turns beating on each other to reinforce the principles of competitive cooperation. It was a fantastic course.

Much of the course principles were things I already had lots of exposure to, but there were some neat techniques in the course delivery that I thought were really first rate. It has been some time since I was in the instructor seat and such a hands-on course was a good refresher for me. The instructor Michael James is a little zen, but did an excellent job modeling the behaviors for the class.

If you haven't taken a Scum course, I highly recommend the training. Even if you don't intend to follow an adaptive methodology, the teaming techniques can be reliably executed in almost any environment.

Social Networking Sites

Lately I've been watching a couple of social networks really take off. Mostly from the standpoint of how I might take advantage of their numbers for various professional reasons.

As I've been considering each of their unique perspectives, usage models, and participation, it was interesting to me how many of them really only thrive on a form of peer-pressure. They don't have to actually be valuable in and of themselves. You simply get sucked in because someone you know dragged you into it via their email address book.

Obviously someone must be finding value in these services or they wouldn't thrive. But how much energy are those who really find the services rewarding putting into them? Is this just another avenue for someone who already spends significant effort? Or does it help even the generally anti-social to become more social?

Have you been one of those lurkers who doesn't participate? You join and then forget about it. Were you at one time? What prompted your activity? Did you one day recognize some value, or have one of the sites serve some need? Did that create a turning point for you?

I can't help but think that these services are only as good as the value that individuals put into them. But then empirical evidence counters that the case must be different. Otherwise, how would any peer-to-peer technology ever take off? Surely even the sum of a bunch of lurkers must provide some value. And every time a lurker becomes involved, even if only marginally, that must increase the value of the system in a meaningful way.

Now I have to go research this. Anyone have answers they give to save me some reading?

DSL Factory Utilities

Lately, my team has been doing quite a bit of work using the DSL Toolkit. It has been quite a grind, but we've developed some pretty cool abilities.

Now I find that we weren't the only ones struggling and that help is on the way for the guys who start on this path next. Thanks for coming to the party guys!

The dslfactory community posted some great stuff on codeplex: http://www.codeplex.com/DslFactoryUtilities

If you are working with the DSL Toolkit even a little, you should check this out.

Microsoft eScrum

It was a quiet release, but Microsoft released a new offering in the Agile space built on Microsoft Team Foundation Server. Here is what the release says:

eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help.

You can download it here.

Looks like things are heating up!

Sharing Agile

In the spirit of sharing, today's post is some reading suggestions for all you agile developers out there. If you are serious about becoming more agile in your development, here are some books you should absorb:

	Agile Software Development by Alistair Cockburn
	Agile Project Management with Scrum by Ken Schwaber
	Agile and Iterative Development by Craig Larman
	Extreme Programming Explained by Kent Beck and Cynthia Andres

When you've finished with that, shoot me an email and we'll move on to real-world examples.

Gears of War

This is not a post about video games.

First it was Docs & Spreadsheets, now Google is once again cooking up some interesting things that reach beyond the search universe . Check out http://code.google.com/apis/gears/ for an overview of their latest offering.

It's a great concept, if late to the party. In their case, that might not matter. We saw this before with Java, we see it currently with Ajax and we'll see it again tomorrow with another challenger. Everyone wants a piece of the desktop pie and there will be no end of challengers.

Don't get me wrong, I don't think the PC is the end-all, be-all, but I recognize clearly that corporations want stable, feature-rich, controlled applications that can be delivered by inexpensive resources. Many of the initiatives in the last few years have forgotten that businesses run by different rules than individuals. What you put up with and is important to you personally is not acceptable and irrelevant to a business. In many cases, the very things you desire for yourself are things that businesses are willing to spend money to ensure you can't have.

In any case, I think this new conglomeration of half-baked technologies has true potential and will be a significant force if it can gain even a small foothold.

Classic isn't Adaptive. Adaptive isn't Agile.

In the world of software development there are many schools of thought on how to go about creating great software. Ignoring the creative side of things such as how you know if software is good, or what solution will meet what business need and so on. Even if you limit the discussion to how you go about implementing a solution once you have identified one, you will still find vastly differing opinions. We call these schools of thought methodologies because they define the method that you use to develop software.

Like all good architects, I too have a method to support my madness when implementing a new solution. My particular approach is thoroughly unique (just like everyone else I suppose ;-)

My particular brand of madness is considered relatively progressive borrowing heavily on the concepts espoused by Agile and Iterative approaches which are fundamentally Adaptive in nature.

The majority of men meet with failure because of their lack of persistence in creating new plans to take the place of those which fail.
--- Napoleon Hill

At the speed in which we are asked to deliver solutions, in an environment in which the business needs remain volatile and the resource allocation continues to be fluid, I feel the only responsible choice in methodology is one that has an adaptive component.

Are you still following a Classic approach? How's that working for you?

This past week I had great opportunities to talk with some charming gentlemen at Microsoft who are working on the next generation of Team Foundation Server and Visual Studio Team System. It was great to see them bringing more adaptive principles into the product. It bodes well for the future.

And for someone who is actively working to solve these challenges now instead of in the future it was very validating to see that our thoughts and approaches were similar. Very validating indeed.

Healing The Sick

The project I am working on would be classified as a Large project by most accepted industry standards. Because of its size, I find myself acutely aware of the differences between small team and large team development efforts. The things you care about and the inefficiencies you can afford are vastly different between these two types of efforts.

Lately, I got a chance to see the movie "The Pursuit of Happyness". In the movie the lead character is trying to become a stock broker and during his internship he has to perform cold-call sales. During one scene the narration explains that in the pursuit of success the character did things to improve his efficiency that others wouldn't. He wouldn't hang up the phone between calls so he could have more time calling. 8 minutes in a day. He wouldn't drink water so that he didn't have to use the restroom during the day. These are the types of things I really identified with.

Now of course, these are very extreme examples but the point is how little inefficiencies really add up. When you are a team of 10 everyone being 10% inefficient is really only about 1 additional body. On a short project you will likely be able to swallow that with some extra hours and extra effort by the existing team. When you have 100 people, the cascade effect from rework and lost time would magnify to a cost equivalent to more than 15 people! And this is even on a short project. As timelines get longer, the magnification is even more impactful.

In software development, optimism is a disease; feedback is the cure.
-- Kent Beck

The ways to counteract this impact from inefficiencies generally require more upfront work to codify engineering processes, checklists, review expectations, and so forth. You need to spend more time lay down the guidance on how the work will be delivered, how teams will get along, etc. When you laying out this guidance the processes will require more oversight, more documentation, and more tracking steps. It will generally require a much heavier footprint then equivalent processes used by smaller teams.

To put it another way, you will spend more time tracking what is being done because you simply must catch issues early and the cost to let things get off track is significantly higher.

Needless to say, I'm getting better at laying processes like that down in written form, but there is much more that could be done. Do you have experiences like this? I'd love to hear how you are handling this issue.

The Business of Software Development

There was an interesting exchange of ideas I witnessed today. The crux of the issue was someone trying to understand the benefits of the Model View Controller (MVC) pattern as socialized by Microsoft. Having some interest in the subject, I watched it grow from a comparison with Event Driven Architecture (a complete misnomer) to contrasting with Model View Presenter (a new flavor of old idea), to just plain batting around the technical merits of various implementations of these common concepts. As one person after another jumped on the band-wagon, virtually everyone had something insightful and technical to say. But none of them brought it back to the business problems. This troubled me as it was indicative of the way we forget that we are in the business of software development. Not just doing software development. Here was my contribution:

--

On many systems we see that there are really two types of logic often treated as the same while they are very different. The first type are UI rules which I’ve seen loosely defined as how we paint screens and provide rich user experience. Then there are business rules which I’ve seen loosely defined as how we manage the data and interactions with the services or repository of the system.

Because we tend to not treat these separately, we also tend to see them tied very closely together in designs and implementations. This presents multiple challenges such as making it harder to encapsulate logic and reuse it and the breadth of knowledge grows (i.e. you need to know UI programming and API/data model programming). MVC is one pattern that attempts to address these challenges, and there are many other patterns that address them as well. Get ready for the twist...

On projects with lots of UI rules that are tied closely with lots of business rules, these challenges are compounded. Especially when you consider how we can go about testing all that intertwined code.

There is lots of anecdotal evidence to support that testability remains one of the biggest challenges on projects with hundreds of interfaces. When looking at the cost/benefit of different designs for large applications we have repeatedly seen cost of testability to be one of the single biggest factors in terms of monetary impact. We can argue a design on technical merits all day long and have differing subjective opinions, but we are in the business of software so we have to be able to quantify the impact of a design in terms of cost also. My personal experience has found that the cost to test is one of the most easily overlooked. Having no one else on this thread bring up the subject as a crucial factor sort of reinforces my point.

Being able to write automated tests is imperative when we have hundreds of UIs. Separating the two types of code means it is significantly easier (read: less time, less custom skill, less money) to craft the thousands of test cases required and the controller logic can be run without additional user windows and workstations. This is because the test cases are standard API code, not rich UI code. In these cases the UI acts as the test without providing an actual UI, instead it just executes the controller to test the business rules.

It doesn’t just make the tests of business logic easier to write, maintain and reuse, it can actually increase code coverage allowing us to get to exception areas of the code that default UI logic would prohibit. For example the UI rules for the initial type of application being constructed don’t allow certain behaviors. However, the controller must be able handle them so that other types of UIs can also be crafted. If we only test against the UI directly (read: the actual UI we are delivering to the users in the first release), we won’t test those hard to reach places. If we don’t test those hard to reach places then when we finally do build the second or third kind of interface and it reaches there, we find new bugs in code we thought was tested well. Automating the controllers allows us to minimize this risk.

To sum up: yes the MVC-class of pattern allows us to encapsulate logic, and yes it can provide significant reuse of code, and very definitely yes it can be argued as good design. But in business terms, we often forget to make the leap to testability as a primary motivator when time to quality gets really small.

Too often we swap our opinions on technical subjects from our ivory towers without considering the business factors that should be influencing us.

--

Whatcha think?

Software Is Like Wine

There is a myth and mystery about software development. It started back with War Games (remember Matthew Broderick, I love that guy!) and continued in the tradition of Hackers and so forth. The engineer creating software is painted as the loner, working in isolation, eating Hot Pockets and drinking Mountain Dew. And sometimes, more and more infrequently, there is an element of truth to this portrait of my brothers.

In reality, the best engineer is a very Social Activity. It requires participation and engagement from many sources, sharing information like wine at a fancy dinner party. Like good wine, there are many steps in the process to produce it, and it absorbs elements of the environment in which it exists.

As I find myself interviewing, training, and growing engineers, I often find myself struggling more for the environment they are growing in, then for the performance of the individual grapes. This tends to not always be obvious to everyone and appreciate how counter-intuitive it can be. We see engineers as isolated and independent. We even call them Individual Contributors. But in reality, they are much like the grapes going into the wine. Sure, they each are unique and add to the end product, but environment has much to do with how they harmonize to create something palatable.

To stretch this analogy even further, consider one step in making this wine (our software product).

When you make wine, you have to squish the grapes. Stomping the grapes can be done in many ways, but I think it could be argued that the most intriguing (read: fun!) way is roll up your pants, wash your feet, hop into the vat and jump around. In many social systems, getting people engaged in the activity of work by releasing the rules of decorum is considered not only an acceptable practice but encouraged. Stomping out the grapes is no exception.

Coming up, I'll explain how a good software methodology is like Stomping Grapes.

My Office. The Quotes.

The project I am working on has me in an office with a whole cast of characters suitable for an 80's screenplay about life as a consultant. In such a testosterone-laden competitive environment there are bound to be a few statements uttered that just cause raucous laughter all-around. For your amusement I've listed a few of the juicier selections from our quote board.

• That is an unwelcome chronological critique.
• Harry is the sugar in my Kool-Aid.
• If you are going to spend at least an hour a day watching tv, you should get a big one. You don't want to surround yourself with things like books.
• If this were VBA, I'd be flying. (VBA is an archaic technology)
• I'm just fast and loose with permissions.
• Try-catch is over rated. (try-catch is how we handle errors in code)
• I haven't yet begun to fall short of expectations.
• It's kinda like karate code.

Part of what makes them so funny is they were all said in seriousness as part of a normal conversation. It wasn't until the statement flew from the lips that it was obvious how silly they sounded.

Of course if you aren't technical some of these aren't going to be funny. Oh well. Enjoy.

Seen Today

The following quote is from a friend of mine. It was his instant messenger tag today...

It is a phenomenally complex set of feelings. Like riding a see-saw, while on a carousel. In a funhouse. In the dark. With bees.

At first, I just thought it was thought-provoking. Then I realized it was insightful. Lastly, it hit me that I really don't like bees.

I hope I'm not one of his bees...