Keith Casey's blog

Outsourced Offshoring!?

Everyone seems to hate outsourcing, but I'm attempting to draw a distinction here. There is outsourcing which I define as "sending work outside your organization" and there is offshoring which I define as "sending work overseas". Both have some potential upsides for the organization in terms of focusing on core skills, benefiting from a larger development team than they have in house, and a variety of other aspects. Both have some potential downsides too. I'm not going into this right now. As a mISV owner, I am all for outsourcing because we couldn't exist without it. I think the jury is still out on offshoring.

I came across an article recently detailing the writer's experience visiting Singapore and Mumbai for a recent wedding and I found the whole thing fascinating.

In order to send work offshore, a certain amount of groundwork must be laid. First, the organization must be able to write a solid specification. Next, someone needs to act as an intermediary especially when the work hours are completely different. Then someone has to evaluate the work stateside. Etc, etc, etc. You get the idea.

It seems that certain offshoring destinations have faced a great deal of wage inflation due to demand for skilled people and the work is starting to move elsewhere. And it makes sense, once an organization jumps the hurdles to make offshoring work in the first place, moving it somewhere else becomes easy and nearly trivial.

Therefore, with the further expansion and improvement of global communication systems, it's impossible to predict where this work will end up going in the long term. The primary destinations at this point seem to be Pakistan, India, and China, but the Ukraine, Romainia, and more rural areas of the others are already picking up steam.

Challenge: Micro ISV Mistake #1

As the distinguished gentleman Gavin pointed out yesterday in Micro ISV Mistake #1 (you might want to read that first), he believes that it's a bad idea "thinking your idea needs to be kept secret". Initially I was fully supportive of this concept - I'm doing it myself - but then I got to thinking about it more as I followed some of the comments.

Ben, Duane, and Chas all pointed out simple scenarios when the oppsite applied. They boiled down to variations of: Prior to your alpha, keep your mouth shut. And I think they're correct.

Everyone knows that execution is everything and that an idea in itself doesn't have much value. This is why patents in the US require a design that *should* work. The concept of the Space Elevator has been around for a century, but only in recent years is it beginning to look feasible. The concepts of human flight, tanks, etc go all the way back to Leonardo Davinci, but it's only been in the last century that these concepts have taken form.

When an idea is embryonic without implemenation, design, or even a fleshed out concept, I believe that it makes perfect sense to keep your mouth shut. Putting your idea out there will give you some early feedback, but it also begins to level the playing field.

In this sort of scenario, I would start discussing my ideas publicly if I had one or more of the following:

  • Personal knowledge, involvement, or connections which would be difficult for another to gain quickly (read: weeks or months).
  • Resources to devote fully and completely to the task very soon.
  • Support and/or endorsement from a large player in my target market or industry (read: if Steve Jobs, Bill Gates, the Pragmatic Programmers, Tim O'Reilly, etc endorsed me, my company, my product, or my idea, I'd make *sure* that you read about it).
  • If being an early mover was huge factor in success, I'd start talking soon and loud.

On the other hand, some things that would make me stay a bit quieter:

  • If I don't have anything besides an idea. Without an execution plan, there's not much value and it would be easier to be duplicated.
  • If all of the pieces or concepts were available and my idea was a new way of putting them together. This might lend itself to fast duplication... which may make it a weak idea anyway.
  • If my idea, code, business was wholely dependent on using information or API's from another group such as Amazon, Google, etc. Asking forgiveness...

Just some food for thought.

Agile Methods need a different mindset

I came across a great article today from Agile Project Planning called: "Do agile software teams make more mistakes?" and he points to the obvious answer of "Yes!" But then he goes into a detailed explanation describing that success comes about quite often because of failure, not in spite of it. True points all and I completely agree, but I'm a bit more pragmatic about it.

As a advocate of Agile Methods, I agree wholeheartedly agree with the idea of fast, tight loops to get customer feedback, design reviews, code reviews, error correction, etc, etc. But in most development, the customer already has a rough idea of their goal and it's your job to figure this out. If you have an excellent requirements gathering/digging team, you probably already have a list of these, but it's nowhere near complete regardless of what the percentage next to the task says. There will always be more that you have to do because of incomplete requirements, unclear requirements, misunderstandings, new customers, etc.

It's an iterative process, so your development should be too.

For example, I live just outside Washington, DC and grew up outside of Chicago. When I drive back, I essentially get on I-70 Westbound, turn northeast at Indianapolis, and turn West again at the appointed place. Little thought is involved because the path is clear, I've driven it quite a few times, and it's major Interstates almost the entire way.

On the other hand, if I go to visit the highly esteemed Duane (a fellow CodeSniper), it takes a bit more effort. I've only made the drive to the area a few times, there are more turns involved, there are state highways involved, and it's to an area that I'm less familiar with. Therefore a completely different mindset is involved:
* I plan the route by looking at the map in advance.
* I keep an eye out for landmarks to mark my progress.
* I watch the odometer and clock to compare actual driving time against my plan.
* And as I get closer, I give him a call to get any last minute changes, detours, etc that might affect my decisions.

When you know exactly where you're going, how to get there, approximately how long it should take, and you've done it numerous times, a waterfall method might work.

If you're unfamiliar with the destination, the route, the effort, and you've done it less than ten times, you need ways of evaluating your progress, establishing baselines and adjusting your route as you go.

This is why I use Agile Methods... because even when I "know" the route, there are a million things that can happen along the way.

Are bad Requirements our fault?

Over the past week or so, I've been reading Marcus Buckingham's First, Break All the Rules. I caught him at a conference last year and finally got around to picking up both of this books, so I've been looking forward to this.

Anyway, I'm approximately half way through it and while I was reading this morning, I was struck by something. Let me quote:

Conventional wisdom asserts that good is the opposite of bad, that if you want to understand excellence, you should investigate failure and then invert it.

He goes on to support this by pointing out that we tend to study things if we want to prevent them: student truancy, drug use, etc, etc. And I found this interesting when applied to some of my recent projects. Everyone tends to focus on "what went wrong and how do we fix it" instead of "what went right and how do we do more of it?"

As is common in the software world, we complain quite a bit about not having a specification. We talk about it to anyone who will listen... and I was actually doing it this morning. Maybe we need to change our perspective a bit. As John pointed out in his recent post, most of our customers and even we take things for granted in how they should work, how we perceive the world, and what we expect from our people and our tools. When we are working with something as intangible and complex as software, we need to focus on making things a bit more tangible and descriptive for our users. We have to make sure that they can understand some of the key things... not *how* we're doing something, but what the tradeoffs are.

I believe that we need to educate our customers on not only what is possible, but what is impossible given their constraints. Not only could this help clarify requirements, but it might completely eliminate silly requirements like "Build an auction system on par with Ebay".

CodeSnipers Lives

Hey, if you've come across the site today, welcome! We're out of beta and not everything is working perfectly, but the bulk of it is. Regardless, we have some great content from some great people with a wealth of experience, skills, and knowledge.

You can read Alex's swift kick in the tail about software documentation entitled: We didn't need documentation back then!.

Or, if you're looking for something a bit more technical this morning, you can read Joseph's review of Cross-Platform GUI Programming with wxWidgets.

Or, if you're not the least bit interested in the code and tools but are concerned about representing and helping the users, you can check out Duane's entry on listening to user feedback entitled: Pave the cowpath.

This is just a small sample of the content available here and with a bit of exploration, you'll find quite a bit more. We have some sharp people sharing quite a bit of wisdom.

And don't forget, if you are particularly interested in a contributor here, they have all written introductory entries and you can check out their personal blog.

Choose the Right Tool for the job

Over the years, I've worked with a number of systems which aggregate data in some way. These have included simple RSS aggregators, the importation of multiple XML formats, and even interacting with a multiple of bug tracking systems. Regardless of the domain, there is a simple concept here: There are a particular set of actions we wish to perform on the data, but quite often the data sources have a variety of data structures.

For some reason, most people immediately jump to the "simple" solution of building a inheritance heirarchy, each with a distinct class/structure beneath it to a specific data structure. This can work fine for quite a few situations and ends up being quite elegant in patterns such as the Data Access Object and others where you can completely encapsulate the data structure and simply forget about it. Unfortunately, this doesn't work in all scenarios.

For example, I'm involved in a large scale Java system where we are retriving XML data structures from a series of different sources (think aggregation). When we started there were twelve different sources in two different formats and the solution looked simple, we would simply import each of the structures and be done with it.

Since I've been bitten by this before, I proposed a different solution. Instead of doing the import in a single step, we would use a Two-Step Pattern to first convert each data structure into our custom structure and simply import that. We've been able to implement this by building a single importer class and creating a new XML-to-XML XSL transform for each new data source.

Just in time too, within 2 months, we were up to 7 different formats from 237 different sources...

A Quick Introduction - Keith

I'm a software developer living just outside Washington, DC. I have worked in both the government and corporate worlds for both internal and external customers. The bulk of my work has involved various Open Source projects in primarily Java and PHP. A significant amount of this development has revolved around the development and usage of various XML standards, but in recent years, I have been working in the integration of existing Open Source Projects.

Last year, I formed my own company - CaseySoftware - based on the belief that small and medium businesses are missing out on critical pieces of technology infrastructure simply out of ignorance of the tools available. There are a number of tools available that can improve workflows, provide better management, and capture information better than the Excel spreadsheets, Access databases, and emails currently floating around out there.

Prior to enter the working world, I began my professional education by earning a BS in Electrical Engineering from Rose-Hulman along with a number of non-technology minors. While there I learned how to flip bits, filter signals, and have an intelligent conversation about various areas of political and economic theory and application. is Live!

Good afternoon and welcome!

If you have found this site prior to August 15th, it's because you've been personally invited. By no means is the site complete in terms of configuration and graphics, so please excuse any oddities that you come across for the next few days. [This posting will stay at the top until then.]

This site is the creation of CaseySoftware, LLC in order to give back and connect the software development community. It is *not* an advertising or promotion site for any particular company, but instead a promotion site for discussion and involvement in the community. Therefore, if you are or become a contributor, we ask that you keep company references relevant to your topic.

What do you get for your experience?

Money? No.
Power? No.
Glory? Unlikely.
Fame? Possibly.
Professional exposure and the chance to demonstrate your expertise? Definitely.

Some basic rules:
* First, the postings must be in English. A conversational style is encouraged, but basic grammatical rules should be followed.
* Second, you should post something - a book review (linked to your Amazon account if you wish), software development issue, a howto, etc - at least once a week. I have found that most of my entries take 10-45 minutes.

If you are interested in becoming a contributor, please drop me a message at webmaster [at] with an example or three of your writing. These can be blog entries, recent articles, book reviews, etc. I need to see that a) you are a competent writer and can contribute to the community and b) you are serious about this opportunity.