Other Than Think

Living in Crazy Town

2011-10-10T13:42:00.003-05:00

DATE: 10/10/2011

FROM: Dan

TO: Development Team Leads

SUBJECT: Idea for new tables going forward

Hi guys,

I got the production DDL for the software we inherited to support from our vendor today, and am thoroughly impressed by the first two tables created in the script:

CREATE TABLE [dbo].[YEARS](
[YEAR] [numeric](4, 0) NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[YEAR](
[YEAR] [numeric](4, 0) NULL
) ON [PRIMARY]

I couldn't find any tables with year type columns in them that had a foreign key constraint to the year (or years) tables. That may be due to the year column being nullable in both of the above tables. But I think this is something we can learn from.

For all of our new databases going forward, I think we should have a primary key table for every kind of numeric value we'll be using in our domain. That will allow us to not only maintain constraint integrity, but also reduce the amount of data we'll need to collect. e.g. Instead of a birthdate column that is allowed to stand on its own without any constraints, I think we should create a birthdate table. Then we'll populate it with all of the birthdates possible. Given we'll have a lot of dates possible, I think we should be efficient with the data and only populate rows where a known birthday has occurred. We could take the lazy route and populate every row with a birthdate, but if you're going to do a job, then you should it right.

Of course this also brings up some political and religious ramifications that our project management staff will need to be aware of. If we base the beginning of human history based on current scientific theories, that would bring us back about 2 million years worth of birthdays. Some would argue that 5,000 years worth of birthdates are sufficient. Given that our field of computer science is relatively new, and hardly considered a true science by any stretch of the imagination, I think that 5,000 years is sufficient.

To increase efficiency even further, we could create an algorithm as part of the birthdate population application to heuristically estimate days when there weren't births on the earth. (Sorry, making assumptions that all births were on Earth so far...but hey, let's be Agile about this and iterate non-Earth births in future releases.) That does mean this algorithm definitely needs to be part of the 1.0 release.

Whew - good stuff. I've got a feeling about this project already!

who needs /etc/passwd?

2011-05-11T16:12:00.000-05:00

A funny thing happened to me today...

I had expanded a zipped file into our development server's /tmp directory, and accidentally littered that directory instead of expanding the files into their own subdirectory.

I wanted to clean those files up, so I started typing:

sudo rm -rf

....but then I thought, maybe I should be safe about it and only remove my files.

I forgot the syntax for removing files owned by a specific user, so I googled it, came back, and pasted in the command to find a given user's UID:

cat /etc/passwd |grep dtanner

then I hit enter.

That command somehow strangely didn't work, but whatever. I cleverly realized I didn't need to read /etc/passwd for my own UID, so I typed "id", got my uid, then did the find and piped my files into the rm command. Problem solved.

But...about five minutes later, one of our developers asked me why he couldn't sudo any more. I thought that was a little odd, since he should've been able to.

I tried it myself, and got the message "user root does not exist".

*gulp*

I figured I had to have been the one to cause this problem, so I did a quick check of my command history. About 10 commands back, I found this brilliant gem:

832 sudo rm -rf cat /etc/passwd |grep dtanner

*cough*. ohhhh fuuuuuuuuuuuu^*.

It actually turned out to not be that severe of a problem. I had a backup of the /etc/passwd because of the /etc/passwd- automatic backup file, and after booting to single-user mode and fixing file ownership of some files that lost their owners during my multi-tasking mayhem, the server was back up.

Choosing a Vendor

2010-12-29T21:58:00.000-06:00

This is another short article on the Cliffs Notes of Software Development series. In this post, I'll offer some tips on how to make a good choice for your custom software vendor. This article doesn't discuss the decision of whether you should build or buy; it assumes you're already down the path of building something - whether it's a completely custom solution, or customizing packaged software.

In no particular order, here are some things you can do that will keep you headed down the right path:

Get assistance from an experienced and trusted guide.
If you don't speak the language and know the turf yourself, find someone that does. For any project that matters, it's far cheaper to get good, unbiased advice up front. Maybe one day you'll be able to rely on your vendor as that trusted advisor, but until they've proven themselves, use caution. It doesn't have to be a long-term engagement; it can be a quick "am I headed down the right path?" few hour session at critical milestones.
Ensure they can communicate technical concepts clearly.
Don't trust a geek that can't clearly translate techno-babble. Our tribe is notoriously bad at glomming onto the latest technical trends regardless of their merit to the business. It's an extremely rare breed of technical advisor that has the experience and wisdom to know when something is a genuine improvement, and not just another revision of a failed idea that a vendor is relying on for their revenue (e.g. Portals, EJBs, ESBs)
Identify and interview the implementation team.
The software industry is still immature by trade standards, and the construction of most new projects requires a lot of experience and mindful improvisation. i.e. The people building the software (not just designing it) can not be commoditized yet (if ever). Most software vendors (especially the bigger ones) will have a mixed bag of staff. You or your trusted guide should hand-pick the people on your project to make sure they're both technically qualified and a good cultural fit. Be suspicious of any vendor that objects to this.
Favor those that have done something like this before.
Sometimes what you're trying to do is truly novel or revolutionary, in which case you should hire a company that specializes on making revolutionary software. For the other 99% of the projects out there, it's already been done before, and those people that have already done it have learned from their mistakes. It usually takes a few tries to build any software right, and if this is the first time your vendor is building something for you, be prepared for it to be wrong the first couple of times. It's just a current fact of life - customers aren't able to specify exactly what it is they want the first time, and builders aren't able to build things exactly right the first time.

Good luck!

Playhouse

2010-10-16T14:17:00.000-05:00

A few months ago, I promised Maria that I would get her and Daniela a playhouse for their birthdays. I was originally going to buy them a little Step2 playhouse, which would've been totally fine. But my good friend Rob, a skilled woodworker, convinced me that building a playhouse was the way to go. I was a little tentative about the idea, since I hadn't built a real structure before on my own, but he very generously offered to help (and with two kids of his own, meant that his wife Karen also very generously to help...we still can't thank them enough!)

So I found this plan, made a few modifications, and off we went:

Starting with a pile of boards...

and a friend who know's what he's doing...

things started to take shape, and a lot of space!

We passed the initial kid inspection...

and had lots of "help".

The first wall goes up...

And the playhouse is now fully operational.

But we realized that it absolutely has to be red.

Much better color!

I finished up the railing in the dark with a million mosquito friends.

One of the owner-operators.

Of course it has to have a doorbell.

and a solar-powered light for late night parties.

And with the trim, it's pretty much done!

Generic Dev Team Recommendation

2010-10-10T23:46:00.110-05:00

A few months back, a friend and I were hired to lead a development team that was to be built from the ground up, to serve as the development arm for an established company that was rebuilding its development group. When we were originally hired, plan A of senior management was to staff the development leadership locally, and offshore the bulk of the implementation team. However, our own experiences in the past gave us the opinion that for this particular situation, the company would be best served by having a single co-located development team.

To be clear, everyone's situations are different, and what I present may not apply to your situation. I have a lot of extremely talented friends and colleagues in this business that live many time zones away, and I've worked on a number of successful projects with them...despite us being widely distributed.

But specifically, why is it so hard? (We are programmers, and communication is often not our strongest skill.) And how does being distributed impact the business? The goal of this opinion paper was to answer those questions, viewing the situation from both a high level (annual operational costs) and low level (a single feature).

ABC Development Team Organization Recommendation

We're currently facing an important decision in determining the ABC development team structure and organization. The goal is to provide ABC with a long-term development capability that is productive, high quality, and cost-efficient. We are currently considering from the following choices:

Create an offshore development center, either independently or in partnership with existing relationships.
Consolidate the development team in one location at the Minneapolis MN location.

Based on the situation and our experience, we recommend a single location for the development team. At a high level, this is because the cost of communication issues associated with distributed teams usually outweigh their advantages.

The Communication Issues Explained

It's difficult to have quality design discussions with distributed teams. For example, ad-hoc whiteboarding is an essential process when communicating complex design concepts. In distributed teams, this is not feasible. Some workaround technologies exist, such as Microsoft LiveMeeting, but they are inadequate replacements because of their technical limitations.
Limited non-verbal communication. Remote teams are restricted to the lowest quality forms of communication - written and voice. This leaves out much more effective styles of communication, such as gestures, body language, eye contact, touch, facial expressions, and posture.
Limited window of communication. Speaking of India specifically in this case, the work day overlap is a couple hours. By regular work day standards (8-5), there is no overlap at all, but teams in this situation accomodate by adjusting their work schedules to work either early or late to get a small window where they can talk.
Slow communication turnaround. Because of the limited window of communication, it takes additional time for issues and tasks to go through their feedback and approval cycle. A typical example is the following scenario: The project manager gives the developer a 2 hour task on a Monday morning, which is the end of that developer's day. On Tuesday morning, the developer has her detailed design questions answered for the task. Wednesday morning, the technical lead is able to review the initial draft of the development and finds some feedback items. By Thursday, the team can mark the issue as resolved and move on to the next task. Contrast this common four-day flow with a co-located team, where the task is resolved in one day.

The Benefits of Co-location

Co-located teams make software faster and more efficiently

Due to the differences in communication quality and efficiency, software with a moderate degree of complexity can be built faster and more efficiently when the team is co-located. It can be built faster due to the quicker feedback loop, as is discussed in the earlier slow communication turnaround scenario. In an ideal situation, developers working around the globe can create software more quickly. This scenario is rarely a reality though, because building anything but the simplest software requires signficant back and forth collaboration. The same communication turnaround scenario also explains how it can be built more efficiently when the teams are co-located. The following diagram illustrates how this happens in real life using a sample four-hour development task.

In the above example, the distributed team gets started on Tuesday morning at 8AM, and finishes Friday at 10:30AM - an elapsed time of four calendar days. The co-located team also gets started Tuesday at 8, but finishes on Wednesday at 4:30PM - an elapsed time of two calendar days. The amount of work is the same in both scenarios, with one small exception. The co-located developer discusses questions she has with the business analyst in person rather than over email. As will be discussed later, this illustrates how you can develop software more efficiently with co-located teams, without doing anything differently other than choose how you locate people. In this example, almost all of the elapsed time differences happen because of the timezone challenge.

As a result, the co-located team finishes this task in nearly half the time as that same time in a distributed situation. In reality, people will have more than one task assigned at a time, so this inefficiency can be mitigated to a degree by multitasking (assigning more than one development task at a time). But multitasking has its own challenges, as context-switching itself drops efficiency levels. There are also times when a person simply has only one thing they can work on at a time, due to project priority or constraints.

In a best case scenario for distributed development, people are always working on something and never waiting, and each task simply takes longer to complete compared to a co-located team. In a worst case scenario, people spend 100% of their time on this task, and it costs the company four days of time and money to implement the feature as compared to two days.

The Cost Factor

There isn't much debate in saying putting people together in a room produces higher quality software compared with separating them. So why do most companies choose a distributed model? Resource availability and cost are the two most common reasons. As resource availability isn't a factor in this case, we're left with the potential benefit of cost in leveraging an off-shore model.

Can we make software that meets the goals of ABC in a more cost-effective way by leveraging an off-shore distributed model? Calculating this is difficult if close to impossible. For example, we can't do what-if scenarios for things like "how many customers will we lose if we build mediocre software?", or "how much is the business impacted if we can't accommodate change in the time required?". However, we can compare most operating costs quite easily. We can also roughly compare development and maintenance staffing costs by making some assumptions about how much additional waste is incurred in the process due to the communication issues.

For example, here are some predicted costs for a distributed team working in timezones with a differential greater than a working day where most development is done in one location and most leadership tasks done in the other.

Contrasting the same task implemented by a distributed with a co-located team, what would be a 12-minute informal chat in a co-located team must be a one hour prepared call in a distributed team. Extra time is required to set up the means to communicate with remote collaborators. For a verbal meeting, this means preparing an online voice or video session; for written correspondence, this means organizing questions or thoughts into complete and concise statements. Hallway chats and quick brainstorming sessions are simply not feasible. The closest tool we have for impromptu discussions when working remotely is instant messaging. Again though, written communication is a weak method compared with other richer forms of communication, where things like body language, inflection, and eye contact can drastically affect the message.

Cost differential at a higher level

The earlier examples show the development process for a single typical task. Another way to contrast costs between co-located and distributed teams is by their annual operational costs. The following tables illustrate those cost differences:

	ABC-Controlled ODC		Subcontract ODC Resources		Local Resources
Major Categories of Expense Differences	Startup Cost	Yearly Cost	Startup Cost	Yearly Cost	Startup Cost	Yearly Cost
Variable Consulting Costs*		325,000		415,000		450,000
Additional Building Lease		10,000
Additional Office Equipment and Services	20,000	10,000
Telecommunication	5,000	1,000
Additional Administration		1,000
Additional Server Hardware and Licenses	60,000	15,000	60,000	15,000
	$85,000	$362,000	$60,000	$430,000		$450,000

		$447,000		$490,000		$450,000

* The Variable Consulting Costs category only shows the yearly burn rate for development. It does not factor in software quality or the amount of features built in that timeframe, which will be higher in a co-located environment.

The consulting cost for distributed offshore resources are lower than US-based resources. In the example of using a ABC-controlled Offshore Development Center, the costs end up being slightly lower due to the additional equipment and maintenance. When partnering for ODC resources, the additional equipment costs actually push the cost higher than operating with a single US-based team.

The Variable Consulting Costs in this table are derived from the following information.

	Annual Cost
Resource/Role	ABC-Controlled ODC	Subcontract ODC Resources	Local Resources
Project Manager	40,000	60,000
India Admin	25,000
US Admin	50,000
Developer	30,000	50,000	65,000
Developer	30,000	50,000	65,000
Developer	30,000	50,000	65,000
Developer	30,000	50,000	65,000
Developer	30,000	50,000	65,000
Jr. QA	25,000	45,000	50,000
Jr. DBA	35,000	60,000	75,000
	$325,000	$415,000	$450,000

The leadership roles are excluded from this table, as they are fixed in the sense that they would be necessary in any case.

Co-located teams make higher quality software

All other things equal, a software team in a single location will produce software that conforms more closely to the intended features, and has fewer defects. To quote Alistair Cockburn's research on the subject:

Osmotic communication makes the cost of communications low and the feedback rate high, so that errors are corrected extremely quickly and knowledge is disseminated quickly. People learn the project priorities and who holds what information. They pick up new programming, design, testing, and tool handling tricks. They catch and correct small errors before they grow into larger ones.

By having a better understanding of the requirements, it can be inferred that the resulting software will also be more fault-tolerant and maintainable. More fault-tolerant because the well-known high risk areas can be engineered more defensively. More maintainable because fewer mistakes go into the design and construction. Cheaper to maintain because business changes cost less to implement. Attempts have been made to quantify the long-term effects of quality on a project, but these metrics are still too subjective and unreliable to be used as an argument in this discussion.

Summary

We've depicted how the reduced cost of a less expensive developer can be offset by inefficient communication. We have also shown that it is likely to take considerably longer to complete a project when using a distributed team. However these examples do not consider software quality, which has lasting effects on cost - from maintenance to scalability, and often with greater consequences than initial cost.

Given our conclusion that the project will cost roughly the same with a co-located team, and have a higher productivity rate with increased quality, it is our recommendation to use a co-located team for this project.

Methodologies at a High Level

2010-08-20T12:44:00.000-05:00

[Part of the Cliffs Notes of Software Development Series]

Merriam-Webster's definition: a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures

So it's how we do things in this industry. Set aside the fact that our industry hasn't figured out a standardized set of methods and rules yet. While other disciplines have had thousands of years to mature, ours isn't even a generation old yet. Not for lack of trying though - we're cranking out new names of methodologies every few years. Sometimes it's just slapping a different label on an old trick, and sometimes it's a genuinely new idea.

These are the most popular methodologies used over the last couple decades:

90s: CMM (Capability Maturity Model), RUP (Rational Unified Process). These were document-oriented techniques that valued heavyweight specifications and processes over human interaction. Each cog in the wheel wrote down what they wanted in an isolated fashion and handed it off to the next party with the expectation that what came back was what they wanted.

late 90s and early 00s: The inception of the Agile movement and its name brands Scrum, eXtreme Programming threw out a lot of the heavyweight process, with an emphasis on the human factor. Their prescriptions are a much shorter list of project guidelines, with some or all of them marked as optional.

mid 00s to today: The above flavors of Agile are the current mainstream choice, along with the somewhat recent additions of Lean and Kanban. Lean and Kanban are direct translations of the auto-manufacturing process, where the goal is to not be wasteful and do what's needed just in time.

What I've said so far is mostly factual. Now for some contextual and subjective quick answers...

So these are the "formal" techniques for making software. You might then wonder how much a particular methodology choice can influence the success (or failure) of a project. In my opinion, not much.

What? How could it not matter much?!!

Before denouncing heresy or ignorance, remember that the software industry is still in an infantile state. We're constantly reinventing the wheel as we arrogantly proclaim the code we just re-wrote to provide the same business function for the last 40 years is once again completely obsolete and needs to be re-written from scratch. We're evolving, yes, and these methodology changes are improving our chances (usually). But the single most notable trait of the recent methodologies is to emphasize the human aspect of the software development process. To err is human. In other words, we know we're a bunch of screw-ups, and the best idea we have so far is to fail as early as possible. Not to scoff at that idea - it is an improvement...the trouble is that we're still failing when we get to the finish line far too often. Don't blame the methodology though, blame the people that didn't do the project right. To put it in kitschy terms: Methodologies don't screw up projects, people screw up projects. More on that in the "It's All About The People" article.

This opinion of methodology isn't anything new, although it's not the norm, especially among those that aren't master software builders, or have something to sell you. I'm sure many professional methodologists would have a problem with what I just said as well. But the funny thing is that the best ones wouldn't.

As an example, what's going to be the next evolution of methodology? Jeet Kune Do! "My style is no style."

Just kidding! Actually, I'm not. Alistair Cockburn (one of the world's best software guides) is starting to teach Shuhari. In layman's terms, when you're a master, you don't need the instruction manual. His Oath of Non-Allegiance request is another example that our trade doesn't yet have the maturity to define a standard on how to create software.

In summary, my advice on methodologies is that you shouldn't worry about any particular name brand. It doesn't really matter. There are definitely some very helpful and specific activities you can do during the process, and for that consult your local (or bring in) experts for guidance. I'll discuss how to find the right people in more detail in another article on this series. Just remember, it's all about having the best ~~resources~~ ~~staff~~ people.

Cliffs Notes of Software Development

2010-07-17T23:05:00.002-05:00

Most of my articles on software development are targeted towards experienced software developers. That world is a weird one though, filled with thousands of unfamiliar terms and concepts that are difficult to relate. The best developers are also excellent communicators, but that's unfortunately a rarity in our breed.

As a maker of custom software, I've seen it happen many times in the past where the buyer is frustrated with this communication divide of understanding, yet needs us to solve their problem and is forced to navigate the process on their own without a trusted guide.

In the small and medium business world, the most common situation is when a business first outgrows their spreadsheets and access forms, and needs a custom solution to better integrate their information. In these situations, most business owners are quite comfortable admitting they know nothing about custom software; they just want someone to solve their problem. Even in the "enterprise" world it's common for a manager to be responsible for a software solution, yet not have any experience in this dirty process of building software. If they're lucky, they'll have a friend in information technology to whom they can ask their "stupid" questions. Often times though there's no one; just them, a budget way bigger than their bonus, and some resources that were assigned to them from who-knows-where. If they're lucky, not only are they all in the same building, but they're sitting within 30 feet of you. Lucky? Why? Just how important is that? Turns out it's really important. But that's just one of topics that can make or break your project's success. Hmmm...well, why doesn't that ever happen? Turns out that a lot of the people making decisions like this are themselves just trying to keep afloat in the sea of change.

So...this series of articles is my attempt to boil down some of these key questions and topics a person might have about this fast-moving and immature industry. Consider it the cliffs notes of software development. Below is the list; each item will be a hyperlink to the details as it is written:

Methodologies at a High Level
Choosing a Vendor
Build vs. Buy
Choosing a Platform
Programming Religions
Costs
Biggest Weaknesses of the Industry
Process Requirements
Suggested Reading
It's All About the People

Top Software Estimating Mistakes

2010-03-11T22:03:00.000-06:00

Aside from a complete lack of planning, this list is about categories of software development that people are aware of during planning, but horribly underestimate. Even smart, experienced people that are usually pretty accurate with their estimates can miss the following things by a mile.

In order from bad to worse in terms of project risk:

#4: The Amount of Testing Required For a Shippable Product

This is actually one of the better known mistakes, especially if you've read The Mythical Man Month. Unfortunately, not enough people in our industry have. And even those that are well aware of the problem are often hard-pressed to effectively address it because it happens at the end of a project, when the buffer (if you even had one) has already been spent on earlier phases. It is one challenge to build a piece of a system, and it is an order of magnitude more difficult to build an entire cohesive system. Yes, test-driven development and better unit testing attitudes, tools and techniques have made a drastic improvement in the right hands, but that last mile always takes much longer than you thought it would when you're trying to put all the pieces together.

#3: Building Uncommon Features
By uncommon features, I mean those features that are treading new ground in some aspect of the tools used to provide those features. For example, nowadays AJAX support is pretty well included in most browsers and development frameworks. But when the functionality was first made available, it was a total bear to develop anything with it. A current example of this is the new features available in HTML 5. Bleeding edge? Yes - blood spent by developers cutting themselves as they fumble through the learning curve and mature the specification.

Knowing the problem is half the battle for these mistakes, and tackling each aspect in a simple and direct way is the best method. If you think the benefit for a particularly ground-breaking feature is worth it, go for it - just remember that it's not going to be predictable, and you will run into some very difficult technical problems that may have already been solved in more traditional ways.

#2: Reporting
The required energy for data reporting is often neglected, with heavy consequences. Why?

The domain of the data being reporting on is often a foreign concept to the people building the software, so we don't know a lot, and miss a lot of important details.
Reporting typically requires the rest of the system to be built first, and since it comes last, it's often the last thing on people's minds.
Flaws in the reporting design can often cause a major ripple effect on the parts of the system that were built to provide that reporting data. This means massive refactoring, and gets even worse if you don't have good automated tests.

#1 - Data migration
Lucky is the project that doesn't involve data migration, because it hurts. It's no fun, it's messy, the business doesn't nurture it, and it almost always goes way over the estimate. Experienced managers will know when a data migration effort will require its own sub-project, with a separate team and early schedule start. Inexperienced leaders will scan a table structure and some sample data, and slap a 20 hour estimate on what turns out to be a 200 hour debacle. Martin Fowler discusses this in his bliki here. As is often the case, he sums up the problem and advice better than just about anyone else can.

So the next time you've got an estimate sitting in front of you, be sure to think about these categories of tasks and think hard about what it'll really take. Then double it. And add 30%.

What kind of software mill do you work at?

2010-03-06T20:50:00.005-06:00

Signs indicating your shop resembles this scene:

People talk about methodology more than features.
You're currently building software using products from IBM, Siebel, or Oracle.
The development manager and infrastructure manager are two different people, and their manager is located more than 30 feet away.
More than 20% of the developers can't solve the FizzBuzz test within 10 minutes.

Signs indicating your shop resembles this scene:

You have at least one app in production successfully running on a dynamic language.
Developers are the ones pushing specific technology to management; never the other way around.
Almost all of the developers sit in the same room or in adjacent offices.
Real consequences exist when people don't meet their commitments.

The Fresh Face Behavior Pattern

2010-01-21T22:17:00.000-06:00

AKA the "That's what we've been saying the whole time!" pattern.

This is another pattern that is commonly experienced in consulting engagements. It's the situation where the existing staff knows what the source of a problem is, but haven't been able to communicate it effectively, or haven't been able to get management to action on their recommendation. I've been on both sides of the equation. It's fun to experience when you're the shiny new toy (the consultant), and is equally un-fun when you're the old hag being ignored (the current staff).

Not to be confused with open, honest communication in a trusting environment where all parties simply want some validation or a second set of eyes to examine a tough problem. This behavioral pattern is usually accompanied by a dysfunctional vibe where the existing management staff doesn't trust the people tasked to do the work. The reason might be because the staff is under-qualified, or the management isn't delegating properly. If the reason for the problem is under-qualified staff, the best outcome is that the consultant can train or mentor the staff into becoming qualified for the problem domain. If the reason for the problem is due to lack of management trust regardless of qualifications, then the problem will repeat itself unless the management can establish a better relationship with the staff. We're talking some serious therapy! But as a consultant, I'm in no hurry to recommend this any time soon. :)

Grails text input field advice trick

2009-11-17T00:21:00.001-06:00

To save space and make the user experience a little better, there's a common technique to set a default value in an input text field to guide a user, that gets removed when the user clicks on the input field. This is accomplished like so:

<input name="q" type="text" value="Search" onclick="this.value = ''" />

(clicking in the box would clear the results)

This is nice, but when used as a search input field, it's also nice to re-display to the user what they searched on when the search results are shown in case the user wants to tweak their existing search criteria.

Here's how to add that feature with just a little bit more code in a Grails GSP page. BTW - you can do the same in other languages, but the syntax will be a little different (e.g. Elvis operators are unique to Groovy).

<input name="q" type="text" value="${params.q ?: 'Search'}" onclick="if (this.value=='Search') {this.value = '';}" />

So now when the search results are displayed, the user will see what they searched on and tweak them if desired. Nothing mind-blowing, but a nice little pair of features for your users with just a little code.

(clicking in the box won't clear the results)

A luser's guide to Iometer

2009-10-30T22:40:00.004-05:00

Hi, my name is Dan, and I'm a software development luser who sometimes dreams of being a sysadmin. Actually, what I really want is the authority to pick all the cool hardware, but with none of the "the server's down!" accountability. If you hear of that job, lemmeno. In the meantime...

If you haven't lived under a rock during the last 5 years, you're aware that virtualization is taking over. This is a good thing. The trouble is, supporting virtualized environments requires a completely new skill set. The ROI is there, but it takes a real knowledge investment! And if you install virtualized servers in a company with overworked and stressed out BOFH's that aren't able or willing to make that learning investment, you can end up worse off than before.

In this particular case, I installed an instance of JIRA and Confluence for a client as part of our big development project. I've installed it before at a couple other places, and performance has always been really good. But at this client, it sucks. As in 10-second-response-time sucks. The instances are running on the VMWare ESX platform, which is the key variable that's different. The trouble for me as a developer in this problem is that:
a) I'm not a VMWare tuning expert.
b) I'm not a BOFH, so naturally, the infrastructure group hates me. Just kidding, they really like me...I know that knife I found in my "Let's deploy EJBs and crush the souls of our poor operations staff" book was just for fun.

But seriously, what we had here was a real failure to communicate. I knew that this thing just wasn't running right. But I didn't know how to narrow the problem down and quantitatively convince them of the issue. I was able to see that it wasn't CPU bound just by watching the CPU meter. I knew it wasn't the database, because I tried a couple different databases, each with the same performance. During my local testing on my laptop, the full production instance ran great. So I was kinda sure that it was I/O bound, but I needed proof.

Enter Iometer. Iometer is an open source tool, originally written by Intel, and open-sourced in 2001. It's become one of the most popular storage performance and benchmarking utilities available. Even VMWare recommends it as a tool you can use to analyze storage throughput.

I'm still an Iometer n00b, so take what I say with a grain of salt, and teach me if you know more than I do please! e.g. One of the questions I have is this one over at serverfault.

Short story long, the punchline is this: I ran an Iometer test comparing performance between my development laptop (7200 RPM drive) and the virtual server instance running on a SAN. Here's the results:

Pretty amazing, huh? Amazingly bad for the server - it's nearly 3 times as slow as my feeble little laptop! Like I mentioned, I'm not an Iometer expert by any means, and there are different ways to configure the tests. But I'd be surprised if you could configure the tests to find this big of a performance difference between systems that were anywhere near each other's performance.

On how to run the tests - here's one tutorial on configuring it, and here's another. The only tricky things I found:
1. On the Disk Targets tab, there's a setting for the Maximum Disk Size, and it's specified in sectors. It's been a couple centuries since I worked with sectors, but fortunately google is your friend.
2. The user guide is a little confusing about what a yellow disk target icon with a red slash through it means. If it's yellow with a red slash, it just means that IOmeter will need to create its iobw.tst file on the drive when it starts the test - you don't have to do anything. Do select the drive you want to test against though - this will be marked with a little X next to the drive when you select it.

Turns out that diagnosing I/O performance is easier than I thought it would be. Now that just leaves the hard part of trying to get our BOFH friends to fix problems like these when they happen...good luck!

How to share google calendar with family and exchange

2009-09-21T23:08:00.004-05:00

Update 9/22: Google must've seen my post and reacted :)
http://gmailblog.blogspot.com/2009/09/push-gmail-for-iphone-and-windows.html
-------------

A while back I gave my better half my old iphone. I was all jazzed up to be able to sync our calendars, but it turned out to be not as easy as I thought it should be. I know there's mac.me and all, but coughing up all that money to AT&T for their service makes one want to act like their dad with their furnace thermostats. (Thank goodness for electronic thermostats, where you can wage the battle once and be done with it...but I digress.)

Here was the situation:
I have an iphone, have my work mail (and primary calendar) fed through an exchange server, and use google apps (gmail) for my personal email.
My wife has an iphone, and a gmail account.

The mission: Share our family calendar - allowing me to see family events that show up on her calendar, and vice-versa.

You'd think this would be pretty easy, but anyone that's been screwing around with these stupid calendar syncing apps for the last few years knows that it's actually really hard. You can get pretty close nowadays with google's default sharing, and even with neuvasync, but at least when I went through this experiment, neither of those solutions had implemented the ability to notify the invitees if the person adding the event did it through their phone. See this thread and this one as examples of the issue. Notifications *do* work if the person adds an event via the google calendar website, but that doesn't help if you want to add an event through your phone.

But what I did find to work was the above combo + google sync. If I have that running, *and* have auto-accept turned on in my google calendar settings, any invitations that are added to my google calendar account get automatically sync'd to my exchange calendar, which are then pushed out to my phone...voila - near real-time synchonization. This requires an extra step, and relies on the google sync app running, but it solves that problem. Next up - wondering why she still prefers the dead-tree version...

The Youth Soccer Project Pattern

2009-09-05T22:16:00.001-05:00

Have you ever seen a soccer/football game played by 5 year olds?

The Youth Soccer Project Pattern is an observation I've seen, regarding how the members of a project will run around as one big pack, chasing the ball all over the field in committees. In this environment, there also tend to be lots of soccer moms yelling praises at the sidelines (AKA project managers). There might one or two young stars that can make their way through the mess. And there's also bound to be one or two kids that are just hanging out in some corner of the field, picking daisies. In software projects those are often the testers that haven't been properly included in the team, or are those testers who are punching the clock and would rather pick daisies than really get into the action.

Contrast this with experienced teams that have players qualified at every position, and know where they should be at all times. Teamwork consists of short, well executed collaborations. Not to mention the fact that the players have spent considerable time together already, so the osmotic communication is a given. The players know exactly what their goal is. Of course in software, this goal can change drastically based on the situation, but once you're coding, you better know what the end goal is. Otherwise you're just wasting time, and maybe even heading in the wrong direction.

So, what kind of team are you playing with or coaching?

When evaluating design decisions, let the numbers talk

2009-08-05T12:01:00.001-05:00

[The title of this article is as much a reminder to myself as it is advice to others.]

One of my clients has a decision to make about when they should use an ESB to expose services in their upcoming architecture.

What's interesting about this decision is that there is a heated debate around it (I say use them only when absolutely necessary, while the company's long-term services company says use them for every public service interface), and this is going to be an expensive decision. It makes for some interesting dynamics in the decision making process.

The conversation became useful when we started talking about concrete ways to compare the approaches for building a particular service. We came up with this rough evaluation criteria:

Category	Tests	Metrics
Performance	1 user, 1 request	response time
Scalability	X users, Y requests per second	avg response time
Initial Effort		Number of hours to implement
Maintainability	Add an attribute	Number of hours to implement
	Change the interface	Number of hours to implement
	Version the service	Number of hours to implement

It's that last category that really intrigued me. It's obviously a difficult thing to measure with all the variables involved, but I think you can get pretty close with some forethought, and maintainability is the key question here. For example, you can eliminate massive developer differences by having the same person implement all variations of the approaches, or at least pick developers that are about the same in skill and speed levels. You'd also want to eliminate (yet still measure) learning curve factors in any approach, since initial learning curves might inappropriately throw off the long-term comparison measurements. You'd still want to measure those, since that's going to be a factor when you need to ramp up another person to support this application.

Ideally there'd be something like the above in a standard format, much like how the Pet Store application is used to compare platform stacks. I did a little bit of searching on this subject to see if there were any other standard operations to consider as part of an evaluation, but didn't find anything worth looking into. What other metrics or tools have others found to be useful in situations like this?

Simple and easy site monitoring with PowerShell

2009-06-29T22:39:00.003-05:00

In the *nix world, I really like monit for watching and managing small to medium apps. A while back we wrote an intranet app in Grails, running on Tomcat on a Windows 2003 server. The client was hosting the app themselves, but didn't have any IT staff whatsoever, so monitoring and managing this app was a little tricky.

I searched around for something like monit for windows, but didn't find any good free or cheap tools to do what it does, which is primarily to monitor and restart services upon failure. There's a million monitor and alert tools out there, but none that I found had a clean way to restart my Tomcat service if something went wrong. The closest thing I found was Hyperic's open source monitoring solution, but after 30 minutes of futzing around, it seemed too klunky to me for this small problem. I'm sure it's fine, and for bigger solutions it would probably fit well.

Then I ran across a couple PowerShell scripts that intrigued me - the first was for scraping a web page. After that find, it was just a matter of googling to find the remaining piece - restarting a windows service. Bingo! I hadn't done any PowerShell scripting yet, but it turns out to be a really sweet solution for this type of problem. All I had to do after that was to tweak the code to be a little more reusable, and I also created a simple grails view that would exercise the integration features I wanted to include in my ping test. From there it was just a matter of calling the script on a regular basis. In my case, I used the windows task scheduler. Here's what the script looks like:

$webClient = new-object System.Net.WebClient

###################################################
# BEGIN USER-EDITABLE VARIABLES

# the URL to ping
$HeartbeatUrl = "http://someplace.com/somepage/"

# the response string to look for that indicates things are working ok
$SuccessResponseString = "Some Text"

# the name of the windows service to restart (the service name, not the display name)
$ServiceName = "Tomcat6"

# the log file used for monitoring output
$LogFile = "c:\temp\heartbeat.log"

# used to indicate that the service has failed since the last time we checked.
$FailureLogFile = "c:\temp\failure.log"

# END USER-EDITABLE VARIABLES
###################################################

# create the log file if it doesn't already exist.
if (!(Test-Path $LogFile)) {
   New-Item $LogFile -type file
}

$startTime = get-date
$output = $webClient.DownloadString($HeartbeatUrl)
$endTime = get-date

if ($output -like "*" + $SuccessResponseString + "*") {
   # uncomment the below line if you want positive confirmation
   #"Success`t`t" + $startTime.DateTime + "`t`t" + ($endTime - $startTime).TotalSeconds + " seconds" >> $LogFile

   # remove the FailureLog if it exists to indicate we're in good shape.
   if (Test-Path $FailureLogFile) {
       Remove-Item $FailureLogFile
   }

}
else {
   "Fail`t`t" + $startTime.DateTime + "`t`t" + ($endTime - $startTime).TotalSeconds + " seconds" >> $LogFile

   # restart the service if this is the first time it's failed since the last successful check.
   if (!(Test-Path $FailureLogFile)) {
       New-Item $FailureLogFile -type file
       "Initial failure:" + $startTime.DateTime >> $FailureLogFile
       Restart-Service $ServiceName
   }
}

I posted my question (and my own answer eventually) on stackoverflow here, so keep an eye on that if you're looking for improvements to it. There's a lot more you can do with this script, like email upon failure, or monitor multiple sites. Hopefully this helps some other folks out there with problems like this. It was a really nice experience for me; simple and powerful. So hats off to the authors of PowerShell - I'll be reaching for that tool more and more in the future.

Domain names for daughters

2009-06-28T22:25:00.003-05:00

Though the biggest domain name purchases are probably long-gone since the initial dot-com boom, they still remain a valued property. They'll never be as valuable as real land of course, since we can always create more of them, as opposed to things like lake-front property.

The recent mad rush for facebook profile names reminded me of this new global scale of gold rush activity. And yes, I'm a little annoyed that someone that has been farming this interweb as long as I have was offered a name like dan.tanner2 (in my day, we used Mosiac. And we liked it!). It also reminded me of something I'm hoping will come in handy for my two daughters some day - their very own short and memorable domain names.

Finding a decent available domain name is a tenaciously difficult PITA. It's an exercise in creativity and luck, and girls names are especially tough. Not only do you have to wrestle with the general lack of availability, but also the likelihood that they'll change their name when they get married. In my case, that's sometime after age 28, when they've agreed to start dating.

In my case, my girls are named Maria Mae and Daniela Teresa. All good variants of maria and daniela were taken, which would've been ideal. And no last names were considered because of the potential marriage name change. After tinkering around for a while, here's what I ended up saving for them:
mariamae.com and danielat.com
They're both fairly mnemonic, and they're both flexible enough to last. And they're both shorter than my domain name!

It'll be a few years, but hopefully they'll be useful. Not to mention give me a little boost in the cool dad category. Not that I'll need any help in that category.

Now...where did my favorite plaid pants go?

In praise of refreshingly efficient meetings

2009-04-14T22:54:00.003-05:00

Everybody dreads bad meetings. Meetings are often too long, too often, or don't accomplish anything. At some companies, this is what they are all like.

You can implement processes to help have better meetings (which is another meeting of course). Heck, I just attended a meeting last week whose title was how to structure our meetings to have less of them.

Like everything else in the thought-based industries, the effectiveness of a meeting is 10% process and 90% people.

The other day, I attended a meeting that was remarkably crisp and effective. It was a brainstorming session, so I wouldn't have expected it. The meeting started with a general leaning towards one solution to the problem, and 15 minutes later (15 minutes early), the meeting ended with a clear path towards the exact opposite style of solution.

I walked out of the meeting thinking, "Wow! That was fun!"
To which I quickly looked in the mirror wondering why the hell I would have just enjoyed being in a meeting. Developers have been bred to hate meetings, so I obviously needed to do some serious soul-searching.

What seemed unique to this meeting vs. so many others were the following attributes:

An inherent sense of urgency by role: The key person in the room was a company officer with a ton of experience making decisions on a limited schedule. Sure, everybody's busy, and some people are really busy, and have that ability to keep people in the room at attention. Maybe it goes with the title, maybe it's decades of experience, maybe a little of both.
Flexibility in thought (an open mind): There weren't any fixed or hidden agendas, which allowed the discussion to flow quickly through the options without getting hung up.
Real-time calculations: Part of the discussion involved ROI. We could've marked that data as follow-up items, which would've left the discussion muddy and forced another meeting, but it wasn't necessary. With the business having a good handle on their critical numbers, and the technology team having a good rough estimate for the project size, we were able to do the math in our heads and flip through the choices in minutes.

The simplest written analogy to this that I've seen is the chapter titled "Rattle Yer Dags" in the book Adrenaline Junkies and Template Zombies, by the legendary Tom DeMarco and Atlantic Systems Guild. (Highly recommended.)

And you can follow the guidelines given when you google "how to run an effective meeting". That's all good stuff...the unfortunate reality for most is that meetings like this don't happen often enough.

So, cheers to refreshingly efficient meetings.

Gotta go...I'm late for another meeting.

Who needs developers when you have IBM?

2009-03-04T10:00:00.003-06:00

It used to be that software vendors sold customers bridges based on the lie that business analysts could write the software with their awesome new tools...eliminating the need for programmers.

I just ran across some interesting marketecture for IBM's Integration Developer product. They appear to have conceded that a BA can't program with the tool. But possibly even worse, the introduction to the product advertises the following:

WebSphere Integration Developer enables integration developers to assemble complex business solutions that require minimal skills, whether they involve processes, mediations, adapters, or code components. Users can construct process and integration solutions using drag-and-drop technology without having a working knowledge of Java.

Sounds like a great plan, huh? Hire an "integration developer" to implement a java-based integration without a working knowledge of java. Because you're just "assembling" complex business solutions...IBM's products take away the complexity for you! Show me someone that fits their target audience that can even properly define the words mediation and adapter.

A couple years back, I saw a presentation at NFJS by Neal Ford that pretty much matched my viewpoint exactly in my own experience. He sums it up in this blog series. Yes, integration is hard. Yes, it takes very experienced developers to get it even done at all, and even those very experienced developers will make a lot of mistakes and produce less than ideal solutions because this is a new field, and remote computing sucks regardless of how smart the solution is.

The bottom line is that you can't hide the complexity under a rug. Products like this will get you 80% of the way there, and by the time you figure out that they're not the right solution, it might be too late. You might have run out of budget, haven't finished, and have a bunch of unhappy customers mad at you. But congratulations, you've just helped your can't-get-fired-for-buying-vendor fund their next line of bridges to sell you.

Want to do it right? Simplify your problem by defining what information needs to go from A to B first, and then listen to the right people that have done this before and aren't getting paid based on how much of their product you buy.

The Development and Infrastructure Team Dysfunctional Relationship

2009-03-01T14:10:00.013-06:00

If you spend any time making software in a big company whose primary job isn't making software, the following patterns about the development and infrastructure teams probably apply:

The development and infrastructure manager are different people.
The managers and their staff sit too far apart for osmotic communication.
They are in calls or meetings together all the time.
Yet angst abounds between the two groups all the time, whether it's overt or simple passive aggression.

If you're lucky, the managers are technically competent and secure enough to have the good hard conversations that are necessary, thinking about things from the customers perspective and from each others perspective. Or if they're not technically current enough to have the conversation themselves, hopefully they can step aside and get the right heads together from each team to figure out things out together correctly.

Unfortunately, as the mighty MC Hawking likes to riff, Order from disorder is a scientific rarity.

Whether it's outright silly and misguided arguments, or the "WTF are they thinking?" kinds of conversations had within each group after a meeting, it seems these two groups consistently spend too much time acting like slashdot commentors and not enough time reading Peopleware.

What's difficult about this problem is that it's not a technical problem. It's the natural result of two diametrically opposed organizational forces.

If the developers would just stop writing crappy software.

If the infrastructure manager would just stop being such a grump.

If the business would just go away.

Believe me - they'd love to. This whole time they're wondering why your crappy system costs them millions of dollars, and still doesn't work as well as their free Picasa photo album, which arguably does more than your system that's shoveling bits from A to B just like all the other thousands of companies exactly like yours. But that's a whole 'nother story coming up...(the software sausage factory from a normal person's point of view).

Is this a cheeky feature, or an ironic bug?

2009-02-23T16:03:00.004-06:00

Line 6 BackTrack Review

2009-02-19T22:13:00.004-06:00

I don't normally blog about the products I buy, but the Line 6 BackTrack rules. I've looked for ages for a good band recording practice tool, and this is finally it. In the past, I've used:

A digital 8 track (too cumbersome)
A portable mp3 recorder with an expensive portable mic (too clumsy and hard to balance, and I had to use some super flaky and buggy software to transfer files)
A laptop (again, too clumsy, and hard to work with on the fly)

Why does the BackTrack rule?

It just works. You turn it on, and it records your stuff in really good quality for practice purposes. Marking stuff you like on the fly is a nice little bonus to help sift through stuff later.
It automatically chops up the files for you based on pauses between sound. No more tedious manual splitting of tracks in Audacity or whatever your file splitting tool is.
It's easy to get the files onto your computer - it works as a USB storage device, so you can drag and drop.
It fits into my guitar case. No lugging some big piece of recording gear around any more, or even worse, forgetting it.

The only issue I had on the first night of practice with it was that I had configured it to a preset of Rock Band levels...meaning its recording threshold was pretty high and the mic gain was pretty low. On one of our lovely ballads, it missed the song's intro because it was below the recording threshold. (Or maybe it's a feature to discourage ballads.) It was easy enough to solve though - I just lowered the recording threshold a little.

All in all, some serious w00t factor...thank you Line 6!

Why Jeff Atwood is one of my programming heroes

2009-02-01T13:34:00.002-06:00

There are a lot of high IQ's in this world, and a proportionately high number of them are in the programming field. But IQ isn't enough. An unfortunately high proportion of the smarties don't have high EQs when it comes to what we're actually trying to accomplish in this field. Jeff Atwood is one of those people whose blog I follow that really, really gets it. Here's a snippet from a podcast between him and Joel Spolsky, where he absolutely nails this concept right on the head.

The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code. To me that's what it's all about. Anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative. If that means using Ruby, or having lots of unit tests: whatever's working for you: do that. But if it's getting in the way, if it becomes friction, like, "I'd love to have this great new feature but I'd have to have 1000 unit tests," that's a negative.

In my opinion, this is the difference between a journeyman programmer and a master. A journeyman has all the mechanical skills that a master has; he knows all the patterns and most of the anti-patterns. But what he lacks is the wisdom to know when to use them, and most importantly, when not to use them.

Maybe someday I'll be able to give Jeff a coke, and he'll smile and throw me a smelly old jersey he used during the project :)

How To Make Skype More Private

2008-12-01T21:09:00.004-06:00

With one of my sisters moving to Japan for a couple years, everyone in my family is now using Skype. By default, Skype is installed to let anyone chat with you and request your contact details. The problem is that you get a lot of Spam and Phishing contact requests.

So, the one thing I recommend everyone do after installing skype is to go into Tools -> Options and change your Privacy settings to be like this:

thought interruptions are life's choppy video

2008-10-24T21:08:00.002-05:00

The other night I was watching the Daily Show through hulu.com in a hotel that had a slow internet connection. About 10 minutes into the episode, the video started getting choppy. I tried ignoring it, but even though the chop occurred only for a split-second, and happened every few seconds, it was distracting to the point where I couldn't watch the show any longer. Everybody knows what that's like. It's the same thing with a slightly scratched DVD. You could theoretically keep watching, but there's something profoundly interrupting to that lack of continuity.

That's the best layman's term analogy I can think of for what it takes to perform a job that requires a deep level of sustained thought. Many have studied and written about this. Some call it flow, some call it getting in the groove. The latest prose in my field is by the gifted Neal Ford.

I make software for a living, which is a field that has a very difficult time quantifying the things that matter about it. Examples at a low level are this:
How do you quantify good code? How do you quantify a good programmer? To this day, it still takes a good programmer to tell them apart - no untrained eye or machine can. The need for uninterrupted thought is another requirement that's easy to overlook and communicate, yet it's absolutely critical to making quality software.

And oh yeah - a faster hotel internet connection. That too. :)

The CDATA board of education

2008-10-14T22:21:00.006-05:00

During my days on the web services team of a big bank a couple years ago, we wrote a ton of web services on the java platform. Almost every service we wrote was SOAP based, and also conformed with a huge pile of enterprise standards that were actually pretty non-standard in the outside world.

The consequence of these slightly non-standard services were that first-time clients of our services sometimes had painful integrations with us. Most notably .NET clients that wanted to auto-generate their client proxy classes. The tool would simply not work with our WSDL, so they had to manually bind to our services, which greatly increased their cost and dates. We didn't care though - the services we wrote were compliant according to our tools, and we simply didn't care that much about the clients that were having trouble connecting to our services. Suck it up, you whiners. We hand wrote all our services from the contract on down, and we're not going to bend over backwards for some whiny .NET'r that can't step outside the confines of his "Add Web Reference" tool.

Fast forward to the last few months. I've written client code for four different service providers. One SOAP, one TCP (I didn't know people still wrote raw TCP-based services!), and a couple XML over HTTP services.

The integration that made me shameful of my former attitude was one of these XML "services" that consists of a large amount of non-normalized CDATA. For example:

<[CDATA[
ColumnHeaderA ColumnHeaderB ColumnHeaderC
aaa bbb ccc
ddd eee fff
ggg hhh iii
]]>

My attitude was that any self-respecting programmer would not be serving up text data that should not be parsed by the XML parser and pass it off as a service, forcing clients to use regular expressions when they should instead be using a proper XML parsing tool. The product manager couldn't understand why I felt that this service was no friend of mine. Their opinion was that it was a perfectly good service, and any average programmer could crank it out in a week.

Why? Because they wrote everything in perl!

It caused me to think back about those clients that I've wronged by not making their lives as easy as it could be. Not to mention gave me another anti-pattern to look out for.

Words of wisdom? When writing a public XML service, do eat your own dog food using different platforms and techniques to evaluate the palatability of your service. Also, write client code for a few other public services to see what feels good, and what's painful from the client's perspective. For example, do you really need to namespace your XML? Does SOAP make it harder or easier for what you're trying to offer? You might be surprised by what you find to be elegant from different sides of the service.

Want a survey? Don't ask!

2008-10-14T22:10:00.003-05:00

Here's a suggestion when you create a survey for your site:
Don't ask for permission - just show the survey.

Meaning, don't pop up a window after the user's completed their shopping, asking them if they wouldn't mind taking a minute to fill out your survey. This is synonymous with telemarketing, and makes most people cringe.

If your survey is really short and to the point, present the survey right then and there. You've already popped up the window. Give them a couple radio buttons at most, and the all-important open comments field. That's where you'll get the most useful responses.

What do I want? System.Exit!

2008-09-25T07:29:00.005-05:00

When do I want it? NOW!

Note to UI builders: When building a confirmation dialog for a user, please don't make them wait to answer the question. I can't think of a time when it's ever really necessary to meditate before making a modal dialog decision.

The most common example of this is Firefox's plugin installer that requires you to wait a few seconds before being allowed to install a chosen plugin. At least you can turn this off in the configuration. A really annoying example I just came across is some new VPN software I'm required to use for one of our clients. Whenever you want to shut down the client, it pops up this dialog:

It starts from 5, counting down to zero before you can click Yes. Every time I see it, it feels like I'm stuck in a room with someone who's re-telling a bad joke for the 5th time. (I'm sure my friends know what I mean :)

So please, a concise confirmation dialog is quite enough.
Don't you think?

Don't you think?

Mark of the Be01100001st

2008-08-18T20:08:00.004-05:00

Satanists and Puritans keep out - I just wanna be able to find where my stuff is in my house. Imagine a world where trying to round up 4 AA batteries isn't a frustrating experience. That's the litmus test for me with home RFID technology. I know, I know...it's gonna be the end of our peaceful human existance (right). I also remember DBAs telling me the same thing when I wanted to use synthetic keys. Oh, the horror.

To be serious, I know there are privacy concerns, and there will be growing pains, but I think this is a pretty minor concern for most situations.

With the "find my rechargeable batteries" example, it could be just like the technology that currently exists to help you find your cordless phone from the charging cradle. You walk around the house with the little beacon device, and like a radio collared wild animal, the beeps get closer and closer until you find those batteries nesting smugly in that {thing-you-forgot-about}.

I guess I'll have to check back in another couple years. For now the price of the consumer level RFID tags are nearly a dollar each, and I can't find a consumer level tagging/searching device available yet. But I definitely think it'll catch on big when it does.

Easy .NET database migrations

2008-08-06T00:07:00.002-05:00

If you've ever written code that accesses a database, then you've experienced the issues brought on in trying to keep the database and code in sync. In their common and annoying form, it's when developer X does something like add a column in his local database, checks in the source code, and then developer Y does a checkout and her code breaks because it's looking for a column that doesn't exist in her local database. In their ugly form, the DBA forgets to add a column when the code goes to production and the deployment is bogged down while people scramble to find and fix the issue. Things like missing indexes can be the worst form of this problem, since the performance problems they can create can be very difficult to track down.

When Mr. Fowler wrote about his colleagues' evolutionary database design, things got better in the development world. I and many others soon hacked up some degree of database migration automation based on the principles outlined in that doc, and not too long later Rails popped up with a great implementation of them.

In the .NET world, it took a little longer for people to come up with their own flavors of this automation. When my homies and I wanted to standardize on a good solution, we found a few decent candidates, and landed on migratordotnet. It was pretty cool. Then my smarty pants colleague Geoff took it and made it production quality. He added a bunch more functionality and did some major refactoring.

Once you start using it, you'll never want to go back. Someday you'll wonder how we ever managed without tools like this in our belts.

The Interview Acronym Quiz

2008-07-23T20:06:00.002-05:00

Here's an idea for your next technical interview - the acronym quiz! Have you ever thought of all the acronyms you've picked up over the course of your career? My first job out of school was as a programmer for a defense contracting company, where I was given an acronym reference book for our domain. I remember someone mentioning an acronym depth competition they had, where the winner was a an acronym 5 levels deep. (e.g. An example of an acronym 2 levels deep is SSA - SCUBA Schools International. 5 levels may have been an exaggeration, but 2 and 3 levels were common, and it was a ton of otherwise useless insider information.

But I digress. This post was about the half-joking idea of adding an acronym quiz section to a technical interview. Of course this has limited value, but it seems useful to answer if you need to go more in depth on a given topic or interview. For example, quickly answer what each acronym means:

SOA
XAML
JAXB
BFF

If your technical candidate didn't get #1, red flag. If they are supposed to know .NET and didn't get #2, red flag. Ditto in the java world for #3. Answer them all, and you just might up end being #4! :)

Netflix and the case of the missing download selection

2008-07-20T22:10:00.006-05:00

So I got a Roku box for Netflix a few weeks back. I was excited, because I feel it's a great next step in the evolution of media deliver. We took a step back for a while there - long ago we had to actually get off the couch to change the channel. Then we got remotes. Thirty years later people were running up to their office computer to change the stream. Definitely not good - especially if we're gonna keep up our American Image.

The good news is that the Roku box and the Watch It Now service works great for the movies they offer. The bad news is that I've watched all 5 of the decent movies they offer. For real. 95% of the movies they offer for their Watch It Now service are either:
a. really old
b. really bad
c. all of the above

Think I'm exaggerating? As an example, the #4 most popular title last week in the Watch It Now collection is "Blushing Bloopers". You can't even *find* that title in IMDB. Other Netflix customers rated it 2.1. Netflix's estimated rating for me was 1.9. Yes, I have exquisite taste; only movies like Slap Shot get a 5 star rating from me. Space Jam was number 10 on the most popular list last week. I did see Dexter in there, which is a must-see IMO for anyone that hasn't seen it.

After my own reaction, I figured a google search would uncover the reason for the skimpy selections, or at least show a thousand other similar opinions, but so far there aren't many people complaining about it at all. For something that's definitely the future, it seems like Netflix is being too tentative in their content offerings. Great - they've solved the delivery problem for another huge potential chunk of the consumer population. But if they're going to succeed, they've gotta offer content worth delivering. I'm sure it's not completely their fault (another case of license extortion?), but they need to solve that problem before they'll get beyond a beta stage of this solution.

So in all, I like my Roku box, but I hope that soon enough I'll be able to waste time watching good TV instead of blogging about bad TV. I'm a busy guy, and I have things to do.

what, me worry about good stack traces?

2008-05-12T14:30:00.005-05:00

Those of us fortunate enough to get to build an application inside sharepoint are often confronted with this error message:

Pretty useful, huh?

What you quickly learn is that the real error is usually found in the shared log, which is usually more descriptive. But every now and then you get a real treat like this as your only source of information:

05/12/2008 14:29:32.84 w3wp.exe (0x03A4) 0x0588 Windows SharePoint Services General 8dzz High Exception Type: System.NullReferenceException Exception Message: Object reference not set to an instance of an object.

Those of us familiar with java development are used to seeing worthless NullPointerExceptions like this, except that further down the stack trace is the clue to what's missing. In this case however, you don't get that clue.

Good thing it's so easy to write functional automated tests in sharepoint :)

My wise colleague Jon Jones pointed me to a roundup of great logging and debugging tips by Andrew Connell here.

On a positive note, my talented colleague Brian Kapellusch wrote a nice wrapper around Spring.NET and NHibernate, which our project is using as the container for our business logic and data access. Craptacular? Yes. Needed? Yes. At least until MS finally gets around to producing a production quality MVC framework, which is probably at least a year off. Without it, I'd have a lot tougher time isolating and testing things like this.

World's Shortest Business Book Synopses

2008-03-08T21:45:00.005-06:00

Welcome to the world's shortest synopses on some of the best selling business titles from the last few years.

Rich Dad, Poor Dad: Doing something you like is for suckers. Money rules!

Good To Great: Step1. Hire smart people. Step 2 ??? Step 3. Profit!!!
Side question - how many executives have lifted the book's title for one of their presentations?

Leadership and Self-Deception: I'm OK, you're not OK is not OK. And think outside the ~~bun~~box.

Me personally, I'm waiting for The Red Queen to become required reading in all executive management training programs. Unfortunately, I still think we're in Kansas, Toto.

One Real World NHibernate vs. TableAdapter comparison

2008-02-26T20:58:00.004-06:00

If you're new to the hibernate vs. old-school data access debate, you hear arguments like:

"hibernate is slow and too hard for regular programmers!"
"manual data access is tedious and non-productive!"
"hibernate is a software Viet Nam!"
"manual data access is people!"

Frankly, most java folks have been sick of this argument long before NHibernate came around. There's truth and FUD on both sides of the argument, but how many people have the time or inclination to compare the two styles of implementation in a real project? (I'd love to hear your real stories - not just "my brother's cousin said that their team totally failed/succeeded on this one big project".)

On a recent small .NET project for a client, I started out creating the implementation using NHibernate, but was then told after my first draft that they'd prefer to stay away from third party tools due to their concerns over maintainability (that's a whole 'nother discussion in itself). So I got to rewrite the exact same functionality using Table Adapters. Since my data access was behind interfaces, it was a great way to see some metrics comparing the two implementations.

The most interesting metric: lines of code

NHibernate DAO: 29
Table Adapter DAO: 534

This was for a DAO with about 30 attributes in its main table, and about 6 one-to-many tables. Of course there were differences in the supporting code, but they were fairly equal in size (actually, NHibernate's supporting code was much smaller too). The biggest "I-can't-believe-Scott-Gu-tells-people-to-do-this" bloat in the TableAdapter code was things like this:
If Not row.IsFooFlagNull Then
ep.FooFlag = row.FooFlag
End If

And all the other garbage syntax that TableAdapters require, including the already-more-verbose manual one-to-many code that has to be written. Yuck - at least that's my opinion for this particular application of the technology.

Not that I'm a Hibernate bigot - I have seen those scenarios where Hibernate simply falls down when dealing with massive amounts of objects, and I'll be the first to say "stored proc?" (Well, maybe not the first.) But for those that are dealing with .NET versions that don't support ORM yet, you really should consider NHibernate for your project.

The wrong milk is coming out of my nose!

2008-02-02T12:23:00.002-06:00

How many times have you grabbed the wrong type of milk and only noticed when you got home? Don't you just hate that? My regional grocer has 22 types of milk sold just under their label, and this type of packaging is sure to elicit some four letter words. Here's a sample of the problem:

Quick - grab a 1/2 gallon of non-RBGH skim for me, wouldja? Oh, and your 3 year old is whining for some chocolate milk. Better hope you don't grab the juiced-up-cow version on accident, or even worse, the friggin whole milk.

So if there are any graphic designers out there looking for a foot in the door at a certain grocer, here's a good opportunity to show them the light.

Capistrano on Site5

2007-11-30T18:27:00.001-06:00

Capistrano makes deployment management easy, once it's configured correctly for the site you're working with. My sites are hosted on site5...the configuration below is a basic example of a working site. It doesn't have mongrel setup, but hopefully that part isn't too much harder after this.

BTW - don't bother trying to get it running on windows/cygwin. It's such a PITA, and I never even got it working, despite many many hours of trying and crying. I eventually used VMWare workstation with an Ubuntu 7.1 installation as my OS. There's some decent documentation out there to get the proper ruby/rails/gems/ and other supporting cast setup for *nix. But site5 also has many required configuration quirks.

So here's the page I created on their wiki:
http://wiki.site5.com/Example_Site5_Capistrano_Configuration

If you find this useful, please pay it forward by keeping that wike page up to date. Their sticky forum pages are a mess. Even better would be a total step by step guide, since there's a lot of other steps that need to happen (covered by other guides)..but it'd be nice to have an all-in-one source somewhere.

The Best Care In The Air (but not on land)

2007-11-30T17:13:00.000-06:00

Yeah, another jab at an airline's nonsensical customer service. But rather than just whine about it, I thought I'd contrast actual interactions between Midwest Airlines and Newegg.com. Midwest, I love your plush leather seats and those oh-so-generous arm rests, but your operations area could learn a little something from the folks that grew Newegg from just another cut-throat online electronics competitor to today's best web retailer...

Here's an email I sent to newegg a while back when their online system charged me a restock fee for a defective product I was returning:

From: Dan
Subject: RMA - 12345 - why restock fee for defective product?

Hi,

I just completed an RMA form for a DVD burner I'm returning for being defective. Can you remove the restocking fee on the refund? It seems wrong that I paid for shipping on this drive twice (here and back to you), and will have to pay for a restocking fee for a drive that's not working right, and then will also have to pay for shipping when I order a replacement burner from you (different brand - I don't want to get that same one).

Thanks,
Dan

And here's their reply:

Dear Customer,

Thank you for contacting Newegg.

Please kindly note that I have issued a credit of $4.87 to cover the cost for the restocking fee of RMA # 205XXX as this item is defective. We humbly apologize for this inconvenience and please allow your card issuer 3-5 business days to process and make the funds available.

In addition, as you are our valued customer, I would like to extend our service by providing a shipping credit of $6.00 towards your next order. Please feel free to let us know by replying back to this email with your new order number so that we can issue the shipping credit onto your account, thank you in advance for your patience and understanding.

If you have any further questions or concerns, please do not hesitate to contact us.

Thank you,

[CSR's Name]

Pretty cool, huh? Now contrast that with a business trip that I'm on right now. I should be flying home right now to avoid an oncoming snow storm that's about to hit Minneapolis tomorrow morning, but instead I'm in my hotel writing negative press about Midwest Airlines. Here's the online chat I had with them yesterday:

Nick: Hello, welcome to Midwest Airlines Online Customer Service. This is Nick. How may I help you?
dan: hi, i'd like to fly back a day early for conf# MXBVBH...
dan: the problem is that the rebooking fee is too high because of the fri/sat night stay restriction. is it possible to get that number down to the $50 fee?
Nick: Unfortunately not. The administrative fee on this ticket is $100 plus any difference in the fare.
dan: or even $150? i can't authorize a full ticket purchase, and i'd much rather continue flying midwest in the future than NWA
Nick: There's nothing that can be done about the fees. They are set in with the rules of the ticket.
dan: c'mon - you can do anything you want...this is my first experience with midwest with many more potential flights to/from MKE in the future, you have the space, and there's a storm coming saturday morning.
Nick: Which flight are you looking at changing it to?
dan: anything friday evening or night would work
Nick: It's an availability issue with the flights, which is why there is the high price. There's nothing we can do as we really don't have anything to work with.
dan: I see 50 seats available on the 9 o'clock flight...
Nick: You do not have the same advance purchase requirement that you got when the ticket was booked inititially.
dan: I'm now painfully aware of the arbitrary rules that are in place. what i'm asking for is a minor exception to be made for a change that won't cost you anything, and will ensure more happy future business from me.
Nick: The only instance in which exceptions are made are in medical emergencies that we can verify.
dan: well, thanks for your time. In the future, I'll be sure to choose another airline.

Not so cool, huh?

In newegg's case, they lost a little bit of money on the transaction, but the strategy has paid off well in the thousands of dollars I've spent there since. Their management gives the customer service reps real authority and a simple guideline to make customers happy (within reason of course).
In Midwest's case, they could have made an extra $150 and ensured my repeat business in the future. No ticket price algorithms. No artificial policy restrictions when talking to a customer.

It's not altruism - it's business. Making customers happy means more money for you.

Oh, so this is how you use hibernate.

2007-11-06T20:57:00.000-06:00

I've been using hibernate for a pretty long time (I was one of the micro donors to help them get hibernate.org), but it's always been a fairly black box to me. It seems every time I use it for a project, I understand something that I was not-so-blissfully ignorant of in the past. Today as I was writing some NHibernate mappings, I ran across this cheatsheet. It's a little out of date (substitute "role" with "name"), but it brings clarity in 30 seconds what the hibernate documentation rarely seems to do for me. It's not that the hibernate docs are bad, it's just that there's so many minute details, and not enough simple samples.

Anyway - kudos to the folks at NDP software.

more than $20 bucks?

2007-10-11T09:29:00.000-05:00

My father-in-law has a running joke about how much things cost. "Is it more than $20 bucks?" is the question. The objects in question are things like boats and rooms at four star hotels. It's a good way to break the ice and have a jolly conversation with someone.

I couldn't help but think of that today as I was asked to take a look at my state's request for proposal (RFP) for a one-license-processing-system-to-rule-them-all. Whoever created the plans for the system is well-versed in the latest industry buzzwords - there's workflow, ESB, hub and spoke, document management, and a whole slew of other systems to be built within this gargantuan vision. Can you imagine one system being built in a state government to handle all 500 different types of licenses possible, replacing the 60 systems that are currently in place? From barber to corrections officer to a license to work with peat - it's all lumped together.

Back to my original amusing observation...on the state's public overview page describing each RFP, here's their estimated cost:
Estimated Cost: Over $50,000

My SWAG - solid seven digit figure. More than $20 bucks?

someday/maybe - shower

2007-09-25T15:27:00.000-05:00

So I just started a new job, and my todo list is huge. Whenever I start a new job, one of the things I like to do is figure out where I can shower after biking in. Makes for a slightly amusing GTD-style list entry on a phone without a full keyboard.