a guy in a room

What's behind that door?
There? That's the office of my star programmer. We can't go in there right now though, I'll have to introduce you later.
Oh? Is he not there?
What? No, he's there alright, but he's been really busy working on an extremely important new feature.

The happy manager might make a joke or two and describe how he likes to slip a pizza under the door every now and then to make sure his star programmer is still eating. Some team members might remark on the fact that they haven't seen their coworker outside his office in a while. It's all good though. The problem is pretty hard and that's why their star programmer gets to focus on it. Just give him time, leave him room and he always delivers.

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.

A guide for changing programming languages

Many projects will encounter a point of frustration with some aspect of Information Technology architecture and developers may clamor for a new technical solution. Changing programming languages may involve a significant rewrite of the software, which is a bad idea most times. However, if you are faced with a compelling technology how should a Project Manager approach the transition? Two personal examples may shed some light on the decision whether or not to change programming languages.

The Eclipse Effect

The hidden cost of cheap tools

I work for a company that’s been undergoing a good deal of change—change for the better, actually. Many of you may be familiar with the famous “Joel Test”, as good a way to judge a development environment as any. Well, when I started working there we scored a 3 out of 12. Not good, but now we’re at seven, and solidly on track for nine. So let me just say three cheers for my work environment. From what I can tell, it’s rather rare for a company to actually sustain any effort at improving how it makes software.

But there is one thing that’s bugging me. Point nine on Joel’s test is “Do you use the best tools money can buy?” In our case, the answer is a flat no.

Okay, so it’s a common complaint. But I think I may have identified (or maybe I’m just getting ahead of myself) a new phenomenon in managerial thinking. I call it the “Eclipse Effect”. It’s like this:

1. Eclipse is a kick-ass tool. (I’m not about to argue this point; it is simply not debatable)

2. Eclipse is free. FREE!

3. Eclipse is open-source, and endlessly extensible.

4. Eclipse is free. FREE!

So, management thinks, this open-source thing is pretty damn nice. Why, open-source tools are great! Why pay for development tools at all?


Why? Because there’s no equivalent to Eclipse in the world of, say, bug-tracking software. (And this is no slam on Bugzilla—it’s a fine tool. But Eclipse is in a class of its own.) As it is, Bugzilla would be a huge improvement over the bug tracker we have now… but we can’t switch. We’ve been trying for well over a year now to get management to loosen their grip on this one, and so far, no dice.

I’m not going to bore you with details. Let’s put it this way: our current system blows, hard. It’s a source of daily frustration and the entire development team hates it.

To be fair, management has reasons for not wanting to switch:
1. It’s the system we’ve had in place for years and years now. It contains a lot of history (in some cases, the only history) of the development of our flagship product.
2. Everyone’s used to it.
3. (The kicker) It works well enough, and besides, it’s free.

It’s the third argument I take exception with. No, it doesn’t work well enough, and that fact makes it “not free”. Because it costs time. When the ‘reporting engine’ doesn’t report, when the ‘perl-powered regular expression search’ fails to find, oh, say, my name anywhere in the issues I’ve created, when search-by-category capriciously drops issues, it costs the company. It costs my time, and the time of whoever I have to bother with questions that would be easy for me to look up if the damn tool was reliable.

So what am I saying, that Eclipse is somehow responsible for this? Kinda, only kinda. I’m thinking that the Eclipse effect has something to do with it. Hey, at least it makes for a catchy title. And though the name may be imperfect, and the diagnosis may be wildly inaccurate, it’s a start. If we as developers start fulminating about the Eclipse Effect like we do with our diatribes for/against SOA, XML, or XP, maybe we can get somewhere. Or at least some decent tools.

Data Access Objects - or- Why CRUD really gets on my nerves

Why I hate CRUD.

BTW: I’m in a bit of, as my husband says "pissy" mood (to which I protest I’m NOT PISSY!!! so it turns into sort of a game). So I’m being a bit sarcastic in this post.

No, not the piles of mouse crud and newspaper shredding you find under a china cabinet when you move your grandparents after having lived in the same house 46+ years EGADS!!!!!!!!!! I’m talking about:

C reate

R replace

U pdate

D elete

When you have an application with sql statements scattered here and there, and then you need to change a fieldname, or table name, or something. What do you have to do? Make sure you update all sql statements that reference that field/table through out the masses of code. What’s more, if you typo’ed a field name, or forgot to add a comma (I’ve done that) then you have to find it and fix it. Wouldn’t it be nice to have all sql queries in one place?

Whats a DAO??

As described by Martin Fowler:
"An object that wraps a row in a database table or view, encapsulates
the database access, and adds domain logic on that data."

This comes up so often in web development, get input from a form, validate, save in database. Select data from database, display. Blah blah blah. This is a “common task” so there is a “common solution” called a Design Pattern, for those of you new to the concept. This particular one is called Data Access Objects (DAOs). There are a number of DAO packages out there or if you like, or you can make your own.

Typically they look like this (the is psudeo-code, only looks suspiciously like php because I think in php!):

Class Person {
var $id;
var $name;
var $age;
var $companyId;

function create($name, $age) {
// sql to create new database entry

function update($name, $age) {
// sql to update entry

function getCompany() {
// retrieves company information, possibly returning a company DAO

function getById($id) {
// sql to retrieve record with id= $id and load values into members

function getByName($name) {
// sql to retrieve record with name=$name and load values into members name and age

function getAll() {
// retrieve all records

PEAR’s DB_DataObject
Works in conjuction with PearDB, probably one of the most popular database abstraction packages out there. (some confuse DAO with Database Abstraction, they are different!) Allows linking with multiple tables. Pretty nice.

DotProject has a nice DAO system, using a class CDpObject. They use ADODB as their db abstraction, but enclose it in an easy to use wrapper.

SugarCRM has a “Sugar Bean” that looks like a DAO system, but I haven’t taken more than a casual glance at it and said “wow..cooool beans”

(TIP: Good way to learn programming – look at Open Source projects and see how they do it! then evaluate to see if its good)

The most annoying is when, you find you need a DAO and are unable (reasons I can’t explain even if I wanted to) to use a DAO package at my job and it just drives you NUTS to write your own when some already exist (hence the reason for my frustration). Some people may enjoy reinventing the wheel, not me. I have more important things to do… I will delvuge somethings in a few days that I've learned about Ruby and DAOs... very cool stuff indeed.

Meanwhile, you can read more about this topic:

Any other links you know of that might be helpful? add a comment!

Thanks, I feel better now. :)

Whether Double-Byte Is ANSI

I'm telling this story because a senior manager flippantly dismissed my careful analysis of an issue, and it got me a little riled up. For about a year as a side project I have been working with people in Japan and Taiwan on converting a Delphi-written Windows tool to Unicode as well as localizing it to Japanese (I am a C++ programmer but picked up Delphi during this project). It is a project that requires clarity on the character set issues involved.

We had an independent expert who audited the Delphi program and cautioned us among other things that we "cannot assume that the non-Unicode character string is always ANSI. When ANSI code page is specified but the non-Unicode character string contains double-byte characters, the two bytes of each double-byte character will be separated." This person was implying that double-byte was different from ANSI in that context.

The glaring problem with his point is that, in Windows terminology, double-byte is ANSI! Plain and simple. Well, read on...

On Windows, ANSI character sets are those that can act as the default non-Unicode system locale character set including double-byte character sets (DBCS). Win32 APIs involving strings generally have an A and a W version (e.g. SetWindowTextA and SetWindowTextW), where the A stands for ANSI and the W stands for Wide Character Unicode. The GetACP Win32 API returns the ANSI code page that the A APIs operate in, which is double-byte (e.g. 932) on PCs configured for Far Eastern code pages.

Thinking ANSI does not include double-byte is understandable because the popular usage of the term "ANSI" assumes that ANSI character sets are single-byte (SBCS). This is due to the origin of the Microsoft usage of the term "ANSI" in the default Western code page 1252 based on a single-byte character set drafted by the American National Standards Institute (ANSI).

It was a misnomer from the beginning because Windows-1252 was not approved by ANSI and it turned out different than the ISO Standard 8859-1. But the term ANSI on the Microsoft platform went on to encompass all of the Windows single-byte character sets in which the lower 128 values are ASCII and the upper 128 vary according to different international sets like Cyrillic.

The Microsoft usage of the term ANSI made a further leap to encompass double-byte character sets. Why is not perfectly clear, but presumably for practical reasons because it was the only term that was handy. DBCS characters can be either 1 or 2 bytes long (don't be fooled by the name "double-byte", they are actually multi-byte -- MBCS), and the 1 byte characters in the lower 128 are ASCII. An ASCII string is exactly the same when it is represented in any Windows (dare I say ANSI) SBCS or DBCS, but Wide Char Unicode is always different. So it is very convenient for the A and W Windows APIs mentioned above to carry the double-byte character sets under the A label. Another practical reason mught be that the ANSI character sets were distinguished from OEM character sets having to do with DOS and hardware, and since OEM included the double-byte sets it was convenient for ANSI to include them too.

There is no dispute about whether Microsoft includes the double-byte character sets among its ANSI character sets. The Microsoft list of Code-Page Identifiers marks the far eastern DBCS code pages (932, 936, 949, 950) as ANSI. The use of "ANSI/OEM" merely indicates that these are also OEM code pages, not that "ANSI/OEM" is some kind of special ANSI (these code pages are listed more clearly as ANSI & OEM on this page).

But there seems to always be fuzziness about this issue. One MSDN article holds back by saying "DBCS can be thought of as the ANSI character set for some Asian versions of Microsoft Windows". Another Microsoft article actually describes "Windows ANSI" as different from double-byte sets due to the lingering association of the ANSI misnomer with the single-byte sets. But the fact is that across Win32 programming, ANSI is always the name for the alternative to UNICODE, and ANSI functions always support the double-byte character sets.

Now to tell about the experience that is the reason for this article, we have to go back to the independent expert's assertion that you cannot assume ANSI for non-Unicode strings. Well I responded that "double-byte character sets such as Shift-JIS are ANSI and since the ANSI strings used in [the program] are based on machine locale you can assume ANSI locale encoding."

But I was chastised by a senior manager (the President of the Japanese subsidiary) who said that "I am a business guy but even I know that what Ben wrote [is wrong]."

Taking sides with the independent expert, the senior manager (showing an instinctive grasp of the subject despite having picked the wrong battle) went on to state: "ANSI does not always mean multi-byte safe. By specifying an ANSI code page the code can't know whether it is pure ANSI (single-byte) or ANSI/OEM (code page 932 - Japanese). ANSI encoding is single-byte by default which may cause double-byte problems. For conversion when the source is in Japanese Shift-JIS, if you just specify "ANSI" (not code page 932 - Shift-JIS), the code will separate the two bytes and do byte-based conversion to Unicode (2 bytes to 4 bytes instead of the correct way - 2 bytes to 2 bytes)."

His statement shows "ANSI confusion" that is understandable considering what I explained above, and points to what could be a legitimate concern if the wrong ANSI code page was applied. However, ultimately this particular disagreement does not depend on the definition of ANSI; the expert made an incorrect assertion that double-byte strings needed to be handled differently in the Delphi program in question. There may be other development situations (none that I know of) where something like this is a concern, but I tested it out and the functions in question worked correctly with the far eastern double-byte as the default ANSI code page.

So do you want the final final answer to the question of whether double-byte is ANSI? The answer is definitely yes, at least in terms of Windows programming, but with regard to discussions with senior management you must allow for variations in the use of the terminology remembering the fact that ANSI is a misnomer in this case anyway.

Myers-Briggs Personality Types and Coping with Coworkers

Do you have any coworkers that you just can’t relate to? Maybe Jim in Marketing, you know the one with a diamond stud in his ear, who plays solitaire while gabbing away for hours on the speakerphone? Or Janice, the DBA you try to avoid at all costs because of her propensity to start an argument over the most trivial of details, “Did you say detach! You better have meant backup and restore, buster! There will be no detaching around here, period.” Or how about Curt, who handles all the Flash animations, but can’t take constructive criticism about his work?

I was surprised and relieved to find insight into why people act the way they do when I stumbled onto the Myers-Briggs personality Type Indicators (MBTI). The MBTI are sixteen categories of personality types driven by psychological preferences, and knowing and understanding a persons MBTI can help you relate to why they act/react the way they do. When you see what drives a person, you can empathize with their position, and you can avoid their trigger points.

Micro ISV Mistake #2

This is the second in a series of posts on common Micro ISV mistakes. Without repeating my entire introduction from the first article, these mistakes are based on lessons learned over the last few years as I started my company, developed our products, and then tried to sell them. Discussion is, as always, welcomed and encouraged in the comments.

Mistake #2 is trying to be all things to all people.

This is a very easy mistake to make. Even if you don’t consciously choose to make a general purpose product from the outset, it creeps up on you. You start with a simple idea, identify a neat little market, plan your development, and know exactly where you’re going. Then you spot another market which you could also serve with just a little extra development, or you decide that if you spent a little more time, you wouldn’t need to limit yourself to that niche; you could attack the entire market. Even if you don’t think of it yourself, someone, an advisor, friend, relative, customer, or potential sales partner, will suggest it to you. It can be seductive and can trick you into feeling like a genius, you’ve gone from a small market to a massive market and you’re just getting started. You’ve actually made a terrible mistake.

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.