This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
As a regular reader of Joel On Software and heading a group prepared to go into the ASP realm with dotProject and Mantis, I read this post with great interest today. It's a long post, but I'll summarize it here:
Software companies and software buyers have directly competing goals from the second the contracts are signed.
Essentially, once a contract is signed, the software company's goal is to continue improving the product or building the next product for the NEXT client, not you. They know you have already signed the contract and have committed to the upfront licensing fees, the annual fees, and it's unlikely that you'll back out. This creates a fundamental disconnect between these two groups that must be recognized.
Phil sees this problem and suggests that an ASP (Application Service Model) model can resolve it if applied correctly. Here are the pearls of wisdom that I've discerned.
First, instead of the standard monthly billing, he suggests a quarterly process. This allows time for problems to be addressed and resolved each cycle without constantly having to rush towards deadlines. Since many businesses work on Net-30 anyway, it makes quite a bit of sense.
Next, you must get buy-in from the client up front. Make them commit to using the tool and making it their own. During the initial deployment, training, documentation, and involvement are a must.
Next, since every customer must be satisfied, the entire entire selling organization has a goal to focus upon. The disconnect of always building the next version while simultaneously supporting old versions becomes a much more financially beneficial thing to do.
Next, it evens out the revenue flows. Instead of having "record quarters" of sales and nothing for months, this will create a more steady growth - as long as customers are satisfied.
Finally - and in my opinion - most importantly, it assures the customer that a huge upfront cost is not being risked for a tool that may or may not fit their needs. Instead of the $100k software going unused, they can simply stop paying for it after six months and only waste $20k.
This is the route that we'll be going with CaseySoftware. Our hosting packages of dotProject and Mantis will be coming on shortly and all monthly plans will have quarterly equivalents offering slight discounts. Hopefully this can assure our customers that the operation and maintenance of their systems are of the utmost priority to us. Towards this goal, we will be announcing strategic partnerships in the next few weeks.
If you haven't read KC's entry On Being "Thorough", go check it out and come right back. I'm addressing the same point from a different direction.
On Friday, I submitted an invoice for a huge amount of hours to our biggest customer. The contract is fixed price, but paid on an incremental basis depending on the functionality of the system, so the absolute number of hours was irrelevant.
KC has kept detailed logs such as:
The first version of the [xxx] table and the [xxx]DAO is almost complete. I have sketched out all of its interactions with the [xxx]. I believe that it would be the best to completely seperate these data structures from all of the interactions with the actual [xxx] themselves.
Therefore, the [xxx] and their evolving structures can be isolated from the table structure. So far, there seem to be atleast 5 xml structures that we will have to deal with along with one that looks suspiciously more like SGML instead of xml. This may cause difficulties.
KC simply uses dotProject as a running log throughout the day taking a few seconds every so often to jot down thoughts, concerns, and questions about the system. As billing time approaches, a bit of editting and cleanup happens to the entries, but they are submitted nearly verbatim.
I spoke with the Project Manager this morning and he said that he was stunned at the level of detail. He said that none of their vendors submit records as detailed as this, not even those who are working on a Time & Material basis. This stunned me.
I believe that if you're going to bill out your time, you must report what is done accurately and completely. Without a high level of detail, two problems arise:
1) the customer cannot know the status of the project and 2) future project estimation suffers.
If software developers and companies want to educate customers, a higher level of service is necessary. This is why all of our customers are granted limited access to our internal dotProject and Mantis deployments.
During the analysis of a codebase from a recent client, I noticed something quite odd...
The bulk of the codebase was of very low quality. Tabbing conventions for denoting loops/if-then statements were not followed, variables were not named consistently, passing data via globals, and whole functions where copy and pasted throughout the code. None of these things in themselves were terrible problems, but combined they caused some difficulties in cleaning the code.
Then, as I delved deeper into the codebase, I found something interesting. There was a portion of the code dedicated to building forums and it was fundamentally different than the rest. The SQL statements were clean, the variables had consistent naming conventions, and a variety of other things that made it clear that this code was not written by the same person. I took a block of code and threw it into Google.
Sure enough, I found a bulletin board system written by a gentleman in the UK which was identical to the existing forum codebase. After some further digging, I found that the license allowed redistribution as long as proper credit was given via inclusion of the complete copyright statements. None were included in the code I was examining, but I wasn't surprised.
This isn't the first time I've seen this. At a former employer, there was a "Senior" Developer who admittedly stole code from Open Source projects and used them within the proprietary codebase. I confronted him numerous times over this and he simply said "In [his country of origin], we don't care about copyrights." This was further evidenced by the fact that he suggested - to the development team initially - distributing the MS Project ISO from the company webpage. He saw nothing wrong with this and once again suggested this in front of the client. [Saner opinions prevailed and this had not occured by the time I parted ways with the organizations. - KC]
In addition, I've noticed this more and more as Outsourced Projects are discussed. If you want to send your code overseas for development, that's your choice. But once you get it back you MUST do due dilligence to ensure that the code is truly yours to use, distribute, and sell under your terms. It is simply too risky otherwise.
You could be inadvertently opening up you and your organization to serious litigation risk by using code from other sources without attribution.
I was contacted yesterday by someone who had received one of my proposals last fall. They loved it, but that project ended up falling through before it went anywhere with me. Regardless, I made a positive impression.
Fast forward four months and the gentleman drops me a message with a description of his latest project and asks if I'm interested. I drop him a quick analysis and within a few hours he calls me. Right off the bat, he says, "Well, I remember how thorough you were in that [name withheld] proposal, so I thought I'd give you a call first."
In all honesty, I didn't believe it was all that thorough. I put together a simple user story describing the interaction with the system. I explicitly stated the known requirements along with a list of unresolved/unaddressed issues. I put together a simple project plan (using dotProject of course!) and included my time/price estimate. I believe that it is better to explicitly state things, be wrong, and have to adjust upfront than have to not find out until the system is being built. Silly me... something that I must have picked up from the PragProg's book The Pragmatic Programmer or from Steve McConnell's Rapid Development.
After hearing this, I started wondering what sort of proposals he has been seeing... I looked around at a few places (Rent-A-Coder, for one, yuck) and I got some of an answer.
Dozens and dozens and dozens of RFP (Request for Proposals) consist of "build me an ebay clone for $200. thanx". First of all, huh? Do you want ALL of ebay cloned? Including the UI... and the feedback system... and the payment system... and the categorizations.. and the affiliates... etc etc. Next, the price is completely absurd. I can't even begin to guess how much effort/time it took to put ebay where it is. I know that I've been using it since 1999 and it's changed quite a bit since then, so I can only assume many man-months worth of effort. [Bad measure of effort, I know. -KC] Finally, the grammar seems to be that of a 13 year old who just got their hands on a keyboard.
The responses are even funnier. They consist of "We are a team of 10 programmers and we can do it by this Thursday. Look at these other 10 sites that we've built!" None of these sites are remotely like ebay, but this person ends up winning the bid. The project then continues on for months, the code is crap, and the buyer is completely disillusioned.
Ladies and Gentlemen, this is what we're competing against in a global marketplace. Don't get me wrong, there are great and terrible developers everywhere. There are great and terrible customers everywhere. What we - as developers - must do is educate our customers on what is required to develop a vision of the system, the requirements, a solid codebase, and a beneficial relationship for everyone.
With this new angle of competition, we can either complain and lose or we can differentiate ourselves from the competition and make the situation better for everony.
I try to stay out of politics and policy here, but I just couldn't pass on this one.
I'm in relatively good health and CaseySoftware is nowhere near the place of having a health plan, so I'm in a bit of a dilemma. Do I attempt to go without health insurance and be one of those 40 million Americans or do I pay through the nose for a plan with reasonable coverage?
The answer: Neither.
For those of you who are in relatively good health, have you ever considered a Health Savings Account? When that Prescription Drug boondogle when through Congress last year, Health Savings Accounts managed to sneak through also.
For those of you who haven't read this blog entry, do so and then come right back. There is some appeal to building a behemoth application that will replace Exchange/Outlook/Evolution and rule the world... muhahah... Realistically, unless we rule the world, that doesn't really do much for CaseySoftware, our developers, or our the bank account.
We believe firmly that a unifying layer of glue between a set of robust Open Source applications is the best way to go. Having a monolithic application is great in a completely homogenous environment where all users fall into the same set of roles and usecases, but the world doesn't work out that smoothly.
This is why we are taking a core set of existing applications - if you don't know, here they are: SugarCRM, Mantis Bug Tracker, and phpBB - to fit them around the core of our favorite application: dotProject. [As a side note, dotProject has just announced: "Target date for 2.0 rc1 is no later than 31 March 2005." - KC] We believe wholeheartedly that dotProject is not only a great tool, but it can serve as a great platform.
Therefore, you Project Manger(s) and developers can use dotProject for all of their work. Your QA people only need to use Mantis for their work. Your support forums - both internal and external - can be in phpBB. And you business development people can use SugarCRM and make sure that projects are progressing as planned. And at any time, the Project Management can look at dotProject and see the status of everything. Each person can do their job and doesn't need to be worried about all of that "other stuff".
But the most important part is what it all boils down to from the original blog entry. NO ONE would be excited about developing an application like this from the ground up... but lots of people are excited about SugarCRM, Mantis, phpBB, and dotProject and the people writing the glue layers are all paid.
Hopefully, we can reap the benefits of both worlds.
Now, let's see if Hula fits into the equation...