Although the Internet is global, and you may do business with people anywhere in the world, most people tend to look for people-networks close to home. Or do they? Should they? If the point of social networking is to connect with other people, ought it to matter where we are?

At Freelock, we have a handful of remote clients, but upwards of 90% of our clients are local. I founded the business on the assumption that people want to know who they’re doing business with, be able to see them face to face, and grow to trust them over time. Nothing breaks the ice like talking about a project in person, over a coffee or better yet, a margarita.

Good or bad, business gets done through personal relationships. How many deals have been cemented on the golf course? It’s a lot harder to say no in person, than it is with a quick dismissive email. So much communication happens non-verbally, through body language, tone of voice, and other channels that just aren’t available online. A video conference is a poor substitute for a face-to-face meeting.

I’ve gotten quite a bit of help from IRC. We have a private company jabber server so when we’re not in the same room, we can still have the feel of a team. We’ve had people helping us out from Bellingham, 120 miles north. The Internet enables some amazing things, and I definitely think it’s possible to work effectively at a distance. Many professions, including writing and coding, can be done quite effectively by individuals working by themselves, anywhere in the world.

But you can’t directly diagnose a connectivity issue in an office in Bellevue when you’re in India, or replace a hard drive. You can’t assemble a car from the other side of the world. And even for creative types who can work effectively on their own, relationships and trust only truly get cemented by meeting their editors, testers, or project managers in person.

Another founding principle of my business is that it’s much easier to ensure quality by having people work in person. If team members can do impromptu code reviews of each other’s work, quality goes up. The solitary developer working late at night may bang his head for hours against a problem that a colleague could solve in a 5 minute conversation. Having a team of people with complementary talents and different strengths working in one place leads to better results.

Once you’ve established that level of trust, remote work becomes more effective. You know when somebody’s cracking a joke, and it doesn’t sound so strange. You’re more likely to ask a quick question in a chat when you can preface it with a comment about an outside shared interest.

Yes, location matters. It’s not everything, and the Internet makes it possible to work together from a distance–but it still matters.

I’ve seen a lot of code in various languages. As a technical writer, I used to write documentation for programmers teaching them how to use a particular interface or system. I’ve been involved with traditional software development projects at large software companies and startups. And I’ve done my share of actual programming of web applications.

I’m finding there are several indicators I look for when evaluating code, specifically for PHP, our language of choice. I’ll go in more depth on each of these qualities in future posts, but for now just thought I’d capture them while they’re fresh in my mind. So when I review code of a web application, here are some qualities I’m looking for:

• Secure. Does the application trust users to provide good data? Does it protect its internals to prevent all the various types of exploits out there? Does it protect data from malicious users?
• Fast. This could mean many things, but I’m looking for efficiency across layers. Is there a database call inside a loop that gets called a couple hundred times? That’s a huge speed killer. I look for code that has an appropriate level of abstraction to the size of the problem–and makes sensible choices about how much data to load for each request.
• Powerful. This one is stolen from Paul Graham. Does the code use object-orientation and inheritance in a powerful way? I like seeing utility methods on base classes, which can then be leveraged to make very short, easy-to-understand final classes. Are the methods attached to the appropriate level of the class hierarchy? How short can you make the main logic of the application?
• Clear. Going hand-in-hand with power, clarity is about making it apparent what each chunk of code is for, and how to go about changing it to make it work the way you want. Clear code is maintainable, well-documented, easy to customize.
• Customizeable. Was the program designed in a way that’s easy to override, easy to customize, easy to run in other environments? Can it be managed effectively, and work broken up into different units?
• Reliable. Does each function or method cover all possible scenarios? Is there proper error-handling in the code? When an end user hits upon some combination of things that the programmer never anticipated, does the program die ungracefully, or provide useful feedback?

Very few programmers hit all of these. My biggest weak area is the reliability one–after reviewing other people’s code, I find a lot less exception handling in my code. We’ve all got something to learn. But reviewing other people’s code can help you spot weaknesses in your own, and develop a much stronger sense of how to do it right.

[Edit: Adding links to more detailed posts as I publish them]

I’m a bit skeptical about their statistical approach to project scheduling… I definitely agree with giving estimates in ranges, but how is your approach that different? Aren’t you depending on arbitrary guesses by the project manager users, to come up with those ranges and confidence values? I’d love to see how you’re addressing this.

Regarding this post: Bruce’s Brain: Multi-Tasking is Killing Your Business, my thinking in developing Project Auriga is that few of our projects are big enough to need a large project management system. What we needed is a task management system, a way of preventing any of the dozens of tasks we need to accomplish in a week from slipping through the cracks. And then making sure we’re billing the right customer for finishing each one. Yes, we’re multi-tasking, quite heavily. But then again, one thing missing from your multi-tasking post was context–you’re taking a very project-centric view of work. There are other ways of optimizing work, which we deal with all the time:

• customer-centric
• system-centric

We manage around 25 servers right now. A few of them we use to host customer accounts. When it’s time for a security upgrade, we might take our list of Joomla installations, and upgrade each one on a given server. Those tasks cross many customers and projects, but since they’re all grouped into one place, we take a system-centric view of this work. So I’m creating a view that makes it simple for system administrators to go down a list and check off systems as they’re upgraded.

Another reason to multi-task is that most of our projects have points where we must rely on outside input. Right now we have 3 Zen Cart projects, 3 Joomla projects, 3 new server installs, and 3 custom development projects that are highly active right now. We do a few tasks on one project, throw it over the fence to the customer, and when they’ve done what they need to do, it comes back to our plate. For example, one of the Zen Cart projects is waiting for the customer to regain control over their domain name so we can purchase an SSL cert and launch. The second one is waiting for the customer to give us a list of products to put into the calendar, and the third is on our developer’s calender next week to do a custom payment module. Meanwhile, our ZenCart person is able to work on one of the Joomla projects.

I guess it’s because software development is one third of our business, and our development projects tend to be small add-ons or changes to existing code. We’re not really in need of full-fledged project management software–we’re in need of a system to capture all the little tasks that need to get done, and make sure they get done and billed appropriately. Project Management, for us, is about identifying the specific tasks, dropping them on somebody’s schedule, and approving the time spent before billing.

Liquid Planner seems to be about managing uncertainty. I’d love to see how they’re attempting to do this–from our discussion last night, my impression is that the project manager estimates a range, and a confidence in that range, and the software then uses statistical calculations to quantify that into a figure to allocate on a calendar. But where does the range and confidence level come from? Isn’t this still relying on humans, on experience, on gut instinct to determine? Does this really add a useful tool to help project managers more accurately determine how long a given project will take, or just more numbers and complexity without actually solving the problem?

My assumption is that it takes 12 months to gain a year of experience… Project Managers only learn how to estimate accurately by doing, and mostly failing, at a bunch of projects. Most of our tasks have been done before, we take measured steps into new territory and allow large margins for error. For our developers, tasks get scheduled up to 75% – 6 hours of any 8 hour day. For large projects, the project manager leaves a few days unscheduled at the end of the project, to allow for the inevitable overruns.

For our sysadmins, who always have stuff to do that comes up each day, we schedule tasks at 50% – 4 hours of each 8 hour day. We add meetings, time off, holidays, etc to the scheduling system so that projects get scheduled around those known interruptions.

I had a client suggest that when presenting an estimate, give the high number first–we’re wired as humans to listen for the first number and take that as what it’s going to cost. Then we can give the factors that might make the project take less time, cost less. Auriga doesn’t try to estimate for you–it simply tracks your estimates, and tasks. We put the high number of our estimated range into the system for scheduling purposes, and try to beat it. That’s also what goes on the sales order, and unless there’s a clear change to the scope, that’s the most we bill. Project Auriga helps us know when we’re going over on a project, helps define how far along we are on a project, and makes our project management transparent to our customers. But it’s no substitute for an experienced project manager–it’s just a tool to keep details from falling through the cracks.

While there is plenty of value in having great tools, I’ve always detested technology that takes more effort to learn how to use than it takes to solve the original problem…

Now there’s also Clear Health. Clear Health has the benefit of a former OpenEMR developer’s experience, and the interface has been greatly cleaned up and enhanced with AJAX to make it clean, usable, and fast. Open source version here.

It also has some integration with SugarCRM.

First of all, a cross-platform desktop project management tool: GanttPV – Open Source Software for Project Management. Many of the desktop-oriented tools are rapidly gaining features comparable to MS Project, mainly in terms of resource scheduling. GanttProject is definitely getting more mature, while Ganttlet appears to be mostly ignored but just the thing for whipping out a quick Gantt chart.

Next, a couple of web-based applications. Achievo is a basic resource scheduling and time tracking application. While the interface seems pretty lame, it has some great plugins available, and may well meet your needs quickly. Finally, Projectory is a Perl-based project scheduling application.

Right now, it reads customers, vendors, and services directly from SQL Ledger. In its next phase, it will transfer hours directly into SQL Ledger invoices!