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.
We've all seen it, we've all been stuck in it. You look at an application, a widget, a feature, or a class and you think "Why did they do THAT? I could do this much better myself!"
Quite often you might be right. There is all kinds of crap code out there. No way to deny it, there are developers out there who haven't bothered to subscribe to any coding standards, standard operating procedures, or habits, and don't even bother looking for any sort of rigorous testing or documentation standards. It feels like fingernails on a blackboard to look at it, let alone make changes to it. But then there is the extreme opposite.
There are beautiful applications, code, and libraries that you look at and marvel. You know the code I'm talking about. You didn't expect to see it and you opened the source and thought "Oh, that's nifty." Then you thought about making a change or writing an Adapter Pattern to add functionality and you realized that either you didn't have to or the Adapter Pattern took 2 minutes to write.
Unfortunately, it seems that most code falls somewhere in between and you can't even tell what end it is on until you delve into it deeply and hit your first brick wall. You stop and think, "Well, I'll just re-write this class/module/feature and it will be much better." Well, maybe...
I'm in a situation now where my boss (not CEO) wants a CRM application. I recommended SugarCRM - after all, I secretly deployed it for the Business Development people a month ago - but he said that we must write it from scratch. I am unsure as to how this requirement exists as their has been zero requirements gathering but it does. Therefore, we must pass on using any of the SugarCRM framework and develop our own from the ground up. This does not seem like an efficient use of resources, but I guess since this is not a cash-strapped startup there are other people footing the bill and this will be utilized to its fullest.
With KC on the road this week, I am encountering the difficulty that more and more Project Managers are running into: a Distributed Development Team. It's every Managers' not-so-secret fear that when the team is seperated by physical distance - and even worse, timezones or cultures - productivity is hurt, communication is weakened, and deadlines can get missed.
There is No Silver Bullet on this one. Sure, as a a boss, I can call my teams every hour. I can email them regularly. I can just tell them to do things. But realistically, does it do anything except annoy them?
I push for a much lighter approach. I make a point of bringing the entire team together - via conference call if I have to - for approximately 15-20 minutes every week and normally longer (1-2 hours) once a month. Each person gets a moment to tell what they're working on, their progress on it, what their priorities are for the next week, and what things are delaying them. At the end, normally a someone pipes up with "oh, I did X. It may be able to help you" and we continue on. By the end of the meeting, people have an idea what's going on, what the focus of the other portions of the team are, and how they can help... or stay out of the way.
Now, back to KC. His fulltime boss has been running him pretty hard with 10+ hour days for the whole week, so he has spent the evenings trying to relax instead of continuing development. Unfortunately this delays our Master Plan(tm), but I believe that the alternative is a unconscious developer putting out crap for code. As an alternative to performing forward development, he has spent a good deal of time hitting our Mantis system logging bugs and comments to bugs for our existing clients. Being away from the core of the system has allowed him to provide some perspective to issues that we had previously overlooked. It's a Forest vs Trees scenario.
In summary, what I'm trying to say is allow your developers to step back from the code once in a while. Make them change their focus to something else for a short period and the new perspective will only deepen their knowledge of the system and allow them to think of and solve problems from a different direction.
This is what we're looking for, right?
As I described before, last week I was forced to fork the codebase on an application that I had previously built a role-based permissions system to handle the variations between the systems.
Well, as I have predicted, development has continued in all four versions and I am being told to merge all of the updates and changes into the latest production systems. For future reference, I'll be calling production & development for one group S-P and S-D and T-P and T-D for the other group.
I have been working extensively in T-P due to my inability to connect to the T-D server reliably. This has caused a pretty large divergence and prevented me from using the group source repository, but I have a local Subversion install, so this is a minor inconvenience. In addition to this, one of the other developers is making significant changes to S-D and fixing critical bugs on S-P at HQ. These changes are going to be pushed out to S-P any moment and now The Boss wants them pushed to T-P asap.
I had planned to do all of this on Monday/Tuesday once I'm back in the office, able to use the main repository, and able to fire up my diff tools on the different servers.
Alas, Ours is Not to Reason Why...
After working a 10 hour day with a 30 minute break for lunch yesterday, we took another 2 hours off and came back to the office until 11pm.
I'm building a Billing Module for the application that I've cultivated since the early Requirements stages. I have 8 pages of requirements, but none of them detail anything useful about the Billing. The only requirements are:
* The system must support billing.
* A markup percentage (0-100%) must be configurable on a per-customer basis.
Obviously the second requirement has some actionable information in it, but the first is a waste of ink. Therefore, I have built a simple Customers table which has all of the customer information along with an decimal representing the markup. I intend to build a simple dropdown where any value from 0-100 can be selected. Eventually, they'll change their requirement and I decided that this would be the simplest way to support the future changes.
Unfortunately, the deltas are escalating between the four systems. I plan to be tied up for a solid day or two trying to re-sync the codebases and make sure that the various bugs and functionality are the same. Arg.
Good Evening and Welcome to my first posting on my own blog. While KC writes and talks about many of the day-to-day operations and the technical aspects of our business, I hope to cover some of the business, economic, and political ramifications of a small Independent Software Vendor (ISV).
And what better to start with than the latest and great issue of Welcome to the Carnival of the Capitalists!
In the meantime, we have filed to be an official business within the state and have received our license to charge salestax. Fortunately, since most of our business is over the Internet and for various remote clients, this should be a minor inconvenience. In the meantime, I am required to file monthly reporting of income in order to access the amount of tax to pay. I've already filled it out once to review the information required and it appears to only take a few minutes a month... except when a check is due.
Have a good evening.
For those of you who may not be aware, CaseySoftware is still in the fledgling startup phase. We have few customers and no one is drawing a salary in order to preserve capital. Therefore, everyone working for CaseySoftware also holds down a regular fulltime job. Sometimes this works out quite well, but other times it makes things quite difficult. For example...
For my fulltime job, I am on the road at the moment. I was picked up by my boss at 5am and we hopped a plane to our 2nd largest office in the US. Upon landing and driving to the office, we spent nearly an hour trying to negotiate a connection to our intranet. It worked... somewhat.
After discovering bad cat5, a bad hub, and a bad dsl connection, we installed the VPN client and went to work. Unfortunately, the connection was a bit too unstable for SourceSafe. We can open a project, browse, and see that things are checked out, but we can't check things out ourselves. Therefore, in order to continue development, I have created a repository using my local Subversion install and have gone from there. Eventually, I will have to re-sync the files with the SourceSafe install, but I'll ignore that elephant for now.
In the meantime, I have found a pocket of non-geeks who use Mozilla/Firefox. I guess there is hope. Now we just need to make all of the apps standards compliant...