I considered for a long time whether or not to blog about this situation. I had decided to keep it quiet but I know there is a steadily growing mISV community out there and I couldn't help but let them in on some of the dark side...

One of the many reasons this blog has been relatively empty for the past six weeks relates to a number of reasons, one of them being a former customer. This former customer - who I have opted not to name at this point - has yet to pay me for work performed in the middle of last year.

Long story short: there is a contract, two phases of work, two acceptances of work from him, and numerous admissions that he should pay. To add to all of this, payment was supposed to be kept in an escrow account towards the purchase of a home. The home was purchased in mid-October... and no escrow account existed. To go a bit further, in order to speed things along, I used his wife as our Realtor and he offered to pay the amount from her commission.

Well, after she performed a miserable job as our Realtor, no check came. After attempting to work with him for two months without progress and even being threatened, I started to follow all the options available. I spoke with a pair of attorneys separately and they reached the same conclusion: CaseySoftware will win, now it's just a question of how much.

I finally gave him one last chance and attempted mediation on February 1st. As a result, he offered 1/6th of the amount due and attempted to place a complete gag order on the entire situation... including the terrible job our Realtor performed. After speaking at length with my attorney, it became clear that the Realtor situation could not be considered as they are legally separate entities and relationships. Let me put it this way, Dan Melson did more for us than our Realtor did... and we just exchanged a couple emails.

Therefore, two weeks ago, I sent his account and all related information to a collections company. I prefered not to and even attempted to work with him long beyond what is required by the contract even after being threatened by one of his partners. He has stuck to his guns of requiring a full release and protection of our Realtor (his wife) and refuses to budge. This makes sense because - according to certain 3rd parties - it looks like her behavior is egregious enough that she could lose her license.

It looks like I have two options:

a) collect the amount of the two invoices; release him, his companies, our Realtor from all damages and action; and agree to a gag order which would prevent me from speaking about this situation in any way, shape, or form... even to the extent of not legally being able to share our home-buying experience; OR

b) pursue each of the situations individually which will likely result in either him paying, getting a lean on his assets , or him attempting to hide assets and/or re-incorporate; and our Realtor could end up losing her license.

While I would prefer to not pursue route b), route a) is simply impossible as I've already talked about various aspects of this situation in previous posts.

When you're working for another company, it's quite a bit different as you will most likely get paid. Sure, the company can go out of business, pull an Enron, or collapse unexpectedly, but there is a bit of predictability there. When you run your own mISV and have a number of people working for/with you, it's quite a bit different. You have to pay your people even if the customer doesn't pay you...

What's the difference between content cloning and content syndication? Is it in the intent? Is it in the process? Or is it something else entirely? Personally, I see this breaking down into three main areas:

First, there quite a few sites out there which are re-syndicating content from blogs, sites, etc. Some - such as Planet MicroISV from Baruch Even - are a great service to the community. The site monitors a huge swath of the software development community and shares it with others. I personally make a point of visiting it on a regular basis and appreciate it.

Next, there are splogs (Ugh... I hate that name.). These sites simply take the content of others, rebrand it as their own, and attempt to get you interested in clicking on their AdSense words. I have a number of keyword monitors on Technorati and these regularly make it into the list. I'm not sure what Google, et al are doing to fight this sort of garbage, but they're smart people, so they'll come up with something. Regardless, the line between these and Planet MicroISV are purely intent, not technical at all.

Finally, there is a third category. These are supposedly legitimate people and companies which take another site's content and claim it as their own. Sometimes they adjust the colors, layout, etc, sometimes they don't. Sites like this concern me. If you believe - like I do - that Google, et al will figure out a way to raise the bar - these sites can cause fundamental problems for your/my/everyone's organizations. The obvious next step is to start comparing the dates of files, sites, etc, but the short term effect could be disasterous. For many organizations, if their site takes a hit in terms of rankings or - worse yet - simply disappears their businesses would simply fold in no time.

So as web developers helping customers upgrade and update their sites, what do we do? Is there a way to combat this? Do we simply contact the ISP's of the offenders to get them shut down? How do we demonstrate which site actually owns the content?

I was recently involved in a CMS evaluation for a rather large client. Their needs were relatively simple but overall they are driven by the lack of a robust web strategy. They have literally dozens of domain names, navigation styles, and even differing content on an entire series of sites spread throughout hosting facilities all over the place. It's a mishmash of things bought and implemented over the past decade or so.

The first suggestion was to bring it all in house. This will allow them to start shutting down hosting accounts, simplify the domain and nameserver management, and allow them to update more easily. This is an ongoing task, not a single step, so keep this in mind.

The next suggestion was to determine what the overall structure would be. You need to know what sort of face you're presenting to the world and determine how the public uses your site. Most of the time you'll want to highlight your products and services, but you also have to put something on your site to convince people to come back. For CaseySoftware, it's our whitepapers and this blog.

The next suggestion was to determine which CMS would be a best fit. They see the value of having a centralized system to manage content across their various sites and have regular updates published. And most CMS's are better than asking the Marketing people to edit raw html.

The final suggestion was to componentize the site. They have a multitude of functionality, information, and tools developed for each of these little sites that are maintained separately and most likely out of sync. Therefore, by moving these components to a centralized toolbox, there can be a single place for all the tools which each page can simply retrieve as necessary.

The formal proposal gets into much more detail with more in-depth suggestions, but this the core revolves around: Simplify, simplify, simplify. Technology is a multiplier on what you can do, not the end solution. Before you launch your site, stop and consider what the point of it is. Are you trying to attract customers? Are you simply trying to have a web presence? Or are you trying to change the world?

Or flavour if you prefer...

I was recently speaking with another developer on a customer site about merging two projects. There is a new project which overlaps quite nicely with what his project does and many of the new requirements are "nice-to-have's" on his project. It seems to make quite a bit of sense, so now all the stakeholders are evaluating this path, but something he said struck me. Paraphrasing, he said "having a second person involved will prevent me from re-architecting it so often. I jump at the flavor of the month." Don't get me wrong, I like the guy, but... Arg.

I think this goes back to Joel Spolsky's Things You Should Never Do, Part I (April, 2000) where he serves up Netscape grilled with a side of fries:
Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

Almost every developer has been inspired to do this. The first time they start working with Design Patterns. The first time they played with Ajax. Their second project. Whenever they join an existing project and/or have to support an old project.

Before you try to grill me up, let me say that there definitely are times when code, architectures, widgets, operating systems, etc should go back to the drawing board and have some of the fundamental concepts reviewed. No matter how great a system is, without regular review, cruft, junk, and bad ideas slip in and infect the code but this must be done deliberately and with specific reasons. I'm not proud of it, but occassionally I still write temp code "because it works" with the hope of improving it later. Sometimes later actually comes...

Anyway, having a second person involved is going to disrupt how he currently does things. There will be some implicit code reviews, more questions asked, and - more importantly - someone else to coordinate with when architecture changes are desired. I believe this is one of the additional strengths of Pair Programming. Not only do the individuals push the pair along, but they also serve as a brake to slow the decision process and deflect the FOTM Syndrome..

With one of our biggest customers right now, I'm working on a series of SMS applications. Neither is particularly complicated, but there's been an interesting disparity between developing each of them. The first one provides special alert information to your phone. The entire system is built in Java on top of a Maven/Tomcat/Struts/Hibernate stack. The other one provides information from a major news organization directly to your phone. This is a one-file php file which parses some XML and sends the message.

I began on the Java application first just a bit before Christmas. While I don't consider myself a Java Guru, I pioneered this customer's Ant build development and testing, so I generally have a clue. Right off the bat, I jumped into Maven, Struts, and Hibernate. I understood the concept of the problem each of these systems was built to solve, so I appreciated their value and dug in. Immediately, I was hit by the sheer amount of misdirection... er... reflection involved, the obfuscated class hierarchies (not the fault of the above applicaitons), and various other oddities and structures required to track down what the underlying code was doing. This was frustrating, but I dug in and started learning about all of it.

The beginnings of it weren't too bad. Reverse engineering the class hierarchies wasn't fun (no source available), but was able to do it with some judicious use of Jad. Following the reflection and references was a whole other story. Getting an overview of how the previous developer arranged things helped quite a bit, but there has still been a relatively difficult learning curve.

Then I was asked to do a similar process in PHP. The concept was almost the same but there was a much smaller data set to use. Eight hours later, I was done. That wasn't all coding. That was tweaking the simple API, ripping apart the XML, adding logging (more than initially requested, but exactly what was finally requested), refactoring the logging into something more useful, tweaking the messages as per customer requests, adding a few other things, and deploying to production (dev was 4.3.x, prod was 5.x). All in all, quite simple... and less code than I have in my struts config file.

The comparison is hard to ignore... and then Caleb on CodeSnipers did this post showing how brain-dead simple it is to implement a Singleton in Ruby.

Is this the death knell for new Java development?

When software developers talk about a project, concept, or just about anything else, we normally speak in reference to models. We use analogies, we make comparisons, we have even come up with the concept of Design Patterns just to improve communication. While making comparisons can speed communication, we must choose the right comparisons and acknowledge that no single comparison is going to perfectly describe all aspects of what we're doing. After all, if there was, why would you be doing it again?

I was reminded of this last week when I was at a family Christmas party and I heard:

Person A: That stuff is as slow as molases!
Person B: It *is* molases.
Person A: (pause) Oh.

As you can probably tell, the comment didn't add anything to the discussion. While the point wasn't to share an idea and/or convince someone else of a model, I found it painfully familiar to other discussions I have heard.

Software development is confusing to many people and black magic for many others. We have a responsibility to make good comparisons and analogies in order to translate for everyone else. Not only can we communicate with customers better, but it allows us to communicate with each other better.

Think about the models and analogies you're using and ask yourself these questions:

Do the comparisons make sense?

If you're talking about email, comparing it to a postcard makes sense for various reasons: it's cheap to send, it's essentially public for everyone to read, and there's little to no guarantee that it will get there in a timely manner.

Do they add anything to the conversation?

If you have a library which simply wraps a different library to give it a standard interface, don't call it a "wrapper". That doesn't mean anything and doesn't add anything. Call it the proper name - an Adapter - and compare it to a US to European electrical outlet adapter.

Where do they fail? and Why do they fail?

Software development is regularly compared to constructing buildings, tending crops, waterfalls, and a variety of other things. When you're working with non-physical pieces that can be manipulated at will and have a near-zero transportation cost, these models only work so far.

Can you use other comparisons to describe those areas?

To describe software development, none of the above descriptions capture it completely, but some capture different aspects. Constructing a building gets to the concept of building frameworks and fleshing out the application. Sculpting a statue gets to the concept of removing unneccessary pieces and simplicity. Evolutionary concepts get to the idea of "survival of the fittest". None of them perfect, all of them useful.

Thanks for reading and Happy New Year.