Blog

If I were given the power to strike one word from the lexicon of software projects, it would be the word "DONE". Too often, clients and developers interpret the meaning of the word "DONE" differently and critical misunderstandings arise.

In the most literal sense, software of any significant scope is never "done". There are always bugs. Even if they have not yet been discovered, they exist. There are always enhancements, refinements, improvements (pick your term) that range from "nice to have" to "can't live without". There are always new versions of operating systems, changes to hardware platforms, new standards, etc. that alter the behavior of software and force updates to be necessary. Software is an asset with carrying costs. And in that sense, software is not truly done until the day it is decommissioned and not used anymore.

Developers live in this world. They know implicitly that software is never "done". So when a client asks, "is the software done?" many developers don't know the right thing to say. I suspect the neural connections go something like this:

- "Is the software done?"

- Hmm. Software is never done.

- The client must be asking something else.

- Maybe he's asking if I've finished implementation.

- I have, so I'll say "yes"!

I call this "Programmer Done Syndrome" and it's a significant source of misunderstandings in contract development. Clients will make important decisions based on the developer saying that the software is done. They'll purchase expensive advertising or announce a ship date to their customers. Then, they'll get a release of the software and find out that it doesn't work. They'll say: "you said it was done. Why doesn't it work?" The programmer will say: "I said it was done. I didn't say I had fixed the bugs!"

I know that I'm over-simplifying, but I really have seen variations of this happen too many times to count, sometimes with very serious consequences for all involved.

So how do you avoid these critical misunderstandings in a client / vendor relationship? Training on both sides.

After nearly 20 years in the software development business, I've come to wish that an electrical shock would zap a developer every time he tells a client "it's done". Don't say that. Be more specific. Say: "We have addressed all known requirements. It is now time to enter a testing phase. During testing, you will test and we will test. We will all log issues in our issue tracking software. We will work with you to prioritize the issues. We will focus first on high priority issues, then on medium priority issues, and lastly on low priority issues. At any time during this process, new issues may arise. Those will be immediately logged and prioritized. The software is "done" whenever you decide that the quantity and nature of the remaining issues is sufficient for your specific business purposes."

That's a mouthful, I know. It's a lot easier to say: "it's done". But it's worth the effort to be specific!

On the client side, it's important to first accept the reality that software is never truly done. This is one of the things about software that you can't change. You can only accept it and learn to manage it. Here are a few suggestions:

1) Be as specific as possible when you ask questions. Don't ask: "is it done". Instead, ask "can we burn the DVDs, stick them in boxes, and ship them to the distributor? After we ship, how will we update the software in the field?"

2) Really consider how important a specific issue is to your business before deciding it's critical. If you consider all issues critical, your software may never ship. Microsoft famously shipped a version of Windows with over 50,000 known bugs. That may make you cringe, but their willingness to do so has made them billions of dollars over the years.

3) Budget for maintenance. After 1.0 ships or goes live, there will still be work to do. That's the reality. You need to plan for it and have the budget for it. If you do, it will make it easier to get 1.0 out the door. You can make intelligent decisions about deferring features and issues until a future release.

4) Parallelize what you can. For example, see if you can lock down the graphical assets so you can get started on the product packaging or marketing website while development continues.

5) Timebox development. Ultimately, software is "done" when the client says it is. Set a deadline and stick with it. Please understand, however, that for this to work, you need to be willing to ruthlessly triage the remaining work.

6) Finally, be careful how you communicate with other stakeholders in your organization. When your boss asks, "when will it be done", don't fall into the same trap as your developers!

Clients who are new to software development often have a hard time accepting the uncertainty that's inherent in the work. They frequently have experience in other industries where the work can be estimated and completed confidently within a narrow range. They expect the same from software projects and are frustrated when their expectations are not met. Past experience has taught them that a group of craftsmen with similar skills and ability can complete the same well-specified task in about the same amount of time. They reasonably ask, for a well-specified software task, there ought to be a "correct" estimate... right?

The answer is "no, not really".

Even for small, clearly defined tasks, different programmers will take different amounts of time to complete them. This is true even if the programmers have similar skills and experience. There are many ways to explain this: Programming is more art than science. The problems are complex. The solutions are non-linear. There are many different ways to accomplish the same thing. Etc. But normally, these explanations fall on deaf ears. If you haven't written software yourself, it's hard to grasp the empirical reality. You may think "OK, I can understand that there are lots of ways to solve a problem in software, but my plumber tells me the same thing when he comes to unclog my drain..."

Instead of casting about for better explanations, I'll describe some real world data. At Art & Logic, the cornerstone of our recruiting process is a programming test - the Art & Logic Programming Challenge (ALPC). We ask all candidates to complete it. It contains several, small, well-specified programming tasks. Candidates complete the tasks then send us their solutions and the time they spent on them.

I collated the results for a subset of candidates: developers we've hired over the past several years. This assures that the data points come from programmers with similar abilities. We don't want to skew the results by including developers who were not up to A&L's standards.

The results are interesting. Here are histograms for two parts of the ALPC:

Both charts resemble normal distributions (i.e. "bell curves") with the addition of one or two outliers. In the first chart, the mean is 3.8 hours. There are two outliers at 2x (where x is the mean) and one at nearly 3x. In the second chart, the mean is 4.4 hours. The outlier is almost 3 times that.

The other thing that's interesting to note is the variability in the normal range. Both charts fall roughly in the range of 4 +/- 2 hours. That's a 300% difference between the low end and the high end.

So what's the take away here?

It's normal for different programmers to take different amounts of time to complete the same tasks. Usually, results will fall within a predictable range, albeit a broad one. Occasionally, a programmer will take dramatically longer. This is normal. It doesn't mean that the programmer has done anything wrong.

If your company is involved in software development, what I have just described as "normal"poses significant challenges to you. How do you confidently prepare a budget and a schedule for your project? How do you keep your project on track? If even good programmers sometimes take much longer to complete things, how do you know if your programmer is good?

The first step in facing these challenges is accepting the reality of the situation. There are many factors that you can influence in a software project. The uncertainty inherent in the work itself is not one of them.

by Paul Hershenson, President

In a simple world, when a client hired a software developer, he would:

1. know exactly what he wanted the developer to build
2. be able to describe it precisely
3. never change his mind
4. not have new ideas once the project started
5. be asking for software that doesn't do anything new or experimental
   

In such a world, it would still be difficult to estimate projects, but at least it might be possible within a tolerable range (say +/- 15%).

In the real world, clients (and developers) are human beings.

Consider some examples:

The client comes to the developer with an exhaustively detailed spec. The developer builds the software to the spec. The client receives the software, fires it up, and can hardly contain his disappointment. It's what he thought he wanted, but now that he sees it in action, he sees how it should have been done instead. Unfortunately, he's stuck with what he's got because he's out of budget.

The client comes to the developer with a simple concept. Maybe there's a page or two of documentation. Maybe not. The developer estimates the project based on the requirements he knows about. What else can he base his estimate on? As the project proceeds, the client fleshes out the concept, adds detail, and, as a result, adds scope to the project. In the end, he's happy with the software but disappointed that it cost so much more than the developer's original estimate.

The client asks the developer to export data from his application to an XML file. The developer complies. Uh, oh. It turns out the client meant "Excel," not "XML," and didn't realize there was a difference. Now he has to go back to his manager and request a new PO to correct the feature.

In the real world, every non-trivial requirement, even the ones that appear to be the best documented, are fuzzy to some degree. Clients have new ideas. They change their minds. They have difficulty explaining themselves. That's the reality in which we live (and developers are no less human!) As a project unfolds, managing uncertainty has a far greater impact on the success of the project than the accuracy of the developer's original estimate.

There are four keys to coping with this uncertainty. They aren't rocket science; they're just plain old common sense:

1) Acknowledge and Accept Reality

It's rare to meet a client who doesn't want the best software, delivered as quickly as possible, for the least amount of money. Hey, I'm a client too on occasion, and that's exactly what I want. But as I discuss the realities of software development with potential clients, and specifically the difficulty in coming up with accurate budgets for the project, they often say things like "I know exactly what I want" and "I won't make any changes."

This rarely plays out in reality. Software is a creative process, and creative processes are not linear. When the client sees the software he has envisioned, he will have ideas for improving it, refining it, and clarifying it. Knowing this and accepting it--embracing it even--is the first key to successfully developing great software. It is a very powerful dynamic when the client and developer commit to collaborate in managing a project's uncertainty.

2) Identify Risks and Mitigate Them Early

When Art & Logic was a young company, we did what was for us, at the time, a large project converting a client's DOS application to Microsoft Windows. I was the project manager. The task list was large, with well over a hundred tasks. I carefully monitored the actual hours billed to each task versus the original estimate. With the exception of two tasks late in the project, each task fell within its estimated range. The client and I both felt good about the budget and agreed to a number of non-critical change requests along the way.

Unfortunately, the two exceptions were quite exceptional. They each took ten times longer than expected to complete. The first task was to interface with a third-party data provider. The second task was to use a third-party tool to produce reports. Today, we would have correctly identified those tasks as risk items and scheduled them early in the project. We would have quickly realized that the risk items had been triggered, and we would have taken steps to mitigate them while there was still room to maneuver. Perhaps we would have switched to a different data provider or used a different reporting tool. At worst, we would have known that we didn't have enough budget to add low priority change requests later in the project.

In general, identifying risks and mitigating them early creates the most maneuvering room for navigating around obstacles.

3) Build Headroom into the Project Plan

By now, I'm sure I sound like a broken record. Going into a software project, expect the unexpected. Plan for it. Allocate time for it. Allocate budget for it.

When we estimate a project, we use a software estimation technique called "Pessimistic PERT" (Program Evaluation and Review Technique). One of us will describe it in more detail in a future post. For now, the key point is this: After all the rigor we apply to creating an estimate, we then add a mysterious, subjective percentage to the total to create a range. Over the years, we've described this percentage as the "Gotcha" or "Safety Margin." It's how we build headroom into the project.

We encourage our clients to do the same. If a project has some headroom, and the developer and client have a strong partnership, unexpected bumps along the way can be overcome.

4) Prioritize, Prioritize, Prioritize

And that brings me to my final point: During most projects, especially toward the end, clients will have to make difficult decisions. If time and money are getting tight, they'll need to decide whether to increase the budget and extend the schedule or defer functionality to later phases of the project. These types of decisions are business as usual during software development and should be anticipated.

The developer must carefully consider what's important to the client throughout the project. He needs to focus his attention on the high priority work and leave the lower priority work for later. That way, if the client has to cut scope toward the end of the project, it will be the lower priority, less important functionality, not the "must have" features that are cut.

The world of software development is anything but simple. I'm reminded of the scene in the new Star Trek movie where Scotty describes transporting an object onto a ship moving at warp speed. Successfully completing a software project can be like hitting a target moving at warp speed. But with strong collaboration between client and developer and the application of common sense, it can be done.

by Tom Bajoras, co-founder

There's a huge amount of information online about the advantages and disadvantages of telecommuting. Type in "telecommuting advantages" or "telecommuting disadvantages" into Google, and you'll get over 1100 results. Casually browsing some of these articles, I get the sense that many of them are theoretical, written by people who have no real experience with telecommuting. Anyone can ask themselves "what might the advantages (or disadvantages) of telecommuting be?" and most people would come up with obvious advantages such as "I don't have to dress nice (or dress at all)" or "it's good for the environment, because I don't have to drive to work," or disadvantages such as "it might be hard to get any work done with all the distractions at home" or "it might be harder to communicate with my coworkers."

Art & Logic has been deeply committed to telecommuting for over 18 years. Ever since the company was founded in early 1991, the majority of our workforce has been telecommuting full-time. We currently have 65 developers spread throughout the U.S. and Canada. Our office in Pasadena has only a small staff. After 18 years, we're in a pretty good position to talk about what telecommuting is really like, or at least what it's been like for us. Presumably much of what we've learned can be applied to other companies who are just now beginning to experiment with telecommuting.

It turns out that there are some surprises. Some of what one might guess is great about telecommuting turns out to be not so great, and some of what you thought would be hard about telecommuting turns out to be surprisingly easy. In short, the advantages and disadvantages aren't all what you expected them to be. Let's examine some of the claims made about the advantages and disadvantages to see if we can distinguish reality from myth.


Claim: Telecommuting workers are better at what they do.
Status: Yes, but not for the reasons you might think.

Telecommuting doesn't automatically make you better at what you do. In fact, the same worker in a traditional office, suddenly converted into a telecommuting worker, may or may not find themself more productive. It depends on the worker. Some people might find distractions at home unbearable, or they might be unable to collaborate effectively in an environment without face-to-face communication, or they might just be too lonely (many people depend on work to provide a sense of a community). But other people might find home to have less distractions than the office (less gossip around the water cooler, less paper airplane battles, shorter lunch breaks), and some people actually communicate better by e-mail. But since most companies recruit people on the basis of how well they work in office environments, the odds are not in favor of the same people thriving in a telecommuting environment, at least not without retraining.

Art & Logic's recruiting process is designed to find people who work well in a telecommuting environment. Since communication skills (especially written skills) are critical, our recruiting process evaluates communication skills just as much as programming skills. Other skills that must be carefully evaluated include time management, social skills, and the ability to multi-task effectively.

Telecommuting companies like Art & Logic can hire the best people, no matter where they live. If our developers had to work in our office, we'd be limited to hiring only in the Los Angeles area. But some of the best programmers don't live in Los Angeles and don't want to (or can't) move there. Since we can hire anywhere in the U.S. or Canada, we can "cast a very wide net" and then raise the bar very high so that very few people get in. The result is a team of the highest quality people that can be found anywhere.

This last effect only benefits companies committed to nationwide telecommuting. Many companies, when they say "telecommuting" just mean people all within driving distance from the office but staying home. Recruiting for a team of stay-at-home commuters has no advantage in its access to a larger talent pool.

Another surprising reason that telecommuters are better workers is that they, on the average, are more experienced. People at a telecommuting company don't have to find a new job every time their life circumstances require them to move. There are many reasons why someone might want to move aside from needing or wanting to find a new job; for example:

• someone's spouse changes jobs, requiring a relocation

• someone marries or starts dating someone who is in another location

• someone wants to move to where their kids will be safer or will have access to better schools

• someone wants to move to somewhere more affordable (perhaps they want to buy a house, or the size of their family is increasing)

This allows projects to be staffed by people who have worked at Art & Logic for a long time and are used to working together.

Lastly, we have a saying, which is "happy workers are good workers, and telecommuting workers are happy." Happy developers are good developers, because they think clearly, are motivated to work hard, are more creative, and spend less time complaining or daydreaming or looking for a new job. And telecommuting developers are happy developers, because:

• they are able to create their ideal work environment without interfering with the freedom of coworkers to do likewise (for example, one person likes to work with loud background music, while another person prefers to work in silence)

• they are able to live where they want to live

• they have more time to spend with their families or pursuing personal interests

• they don't have the stress of sitting in traffic

• they spend less on transportation (gasoline, car maintenance, car insurance)

• they can exercise more and eat healthier

Claim: Telecommuting is not just good for our developers and for our clients; it's also good for the world.
Status: Yes, and for even more reasons than you might think!

Usually when people make this claim, they're thinking of conserving energy resources. Obviously telecommuters use less gasoline in their cars, and companies with a lot of telecommuters can have smaller offices, which means lower energy usage in the office. In fact, a 2007 study commissioned by the Consumer Electronics Association showed that a telecommuter used almost 850 gallons of gasoline less each year. The study went on to claim that telecommuting at that time was saving enough energy to power 1 million households in the United States.

But telecommuting is good for the earth in ways besides polluting less by burning fossil fuels to run cars or generate electricity. Less cars means less highway maintenance (which in turn requires fuel and energy) and less land used for parking lots.

Less driving means less traffic-related injuries and death. (Thousands of people are killed every year while traveling to and from work.)

Telecommuting's benefits to the world go beyond just protecting the environment; there are also subtle but powerful benefits to society as a whole.

By keeping people in their local communities, people have more of a chance to get to know each other. Telecommuting workers are more available for participation in community organizations. Sadly, many commuting workers, in contrast, leave their neighborhood each morning, drive an hour to another part of town where they have no involvement at all, then drive back to their own neighborhood, where they isolate themselves inside their homes. People don't know the names of their next door neighbors, because communication can be avoided on the way to and from the car at the start and end of the day.

Telecommuting also gives people more time with their families. Parents are able to see their children off to school or take a break from their work to participate in their child's activities, or to take care of extended family members who are ill or aging.

Telecommuting increases job opportunities for persons with health problems or disabilities, since in most cases such people have already invested in customizing their home office environment for their special needs.

By strengthening the family, telecommuting invests in its own future. The children of these families grow up to be productive members of society, many of whom naturally seek out telecommuting opportunities since they grew up in a home with telecommuting parents.


Claim: Since people aren't in the office with you, how can you know if they're really working?
Status: Just plain silly.

Of course you can know if they're working... because the work gets done! This question is based on a fundamentally false understanding of the relationship between telecommuting workers and their employers. Art & Logic's developers aren't just "out there somewhere" given a project while we wait until two minutes before the project deadline to ask them if they've finished it. Each project has a project manager; the manager manages a task list, assigns tasks to developers, and verifies that tasks are finished correctly, on time, and on budget. Tasks are usually defined to be not larger than 8 hours, so not more than a day can go by without the project manager knowing that a task hasn't been completed.

Secondly, this question implies that developers would prefer not to be working. The truth is that programmers love to program, and Art & Logic developers love working on Art & Logic projects. They have no reason not to work. They enjoy working, and of course they get paid to do so. (Programmers often joke that they get paid for what they would be doing even if they weren't getting paid to do it.)

Ironically, in many offices people sit around talking about what was on TV last night or surfing the web instead of working, but at least in that case you know that no work is getting done, because you can see the workers not working.


Claim: I can't entrust my company's project to someone I've never met.
Status: Huh?

But of course you can meet us! We'd be happy to meet with you at our office, or at your office, or anywhere else. It just means that whoever you're meeting with might need to travel to get to the meeting.

There's even the possibility that wherever you are, a developer might live near you, which makes it more, not less, likely that you can meet someone.


Claim: Telecommuting saves money.
Status: It depends.

This was the argument in favor of telecommuting most often heard in the early days of telecommuting. There are good reasons why it's not heard as often anymore. On the surface, it would seem to make sense that a company can save money by having a smaller office (less rent, utility bills, office supplies) But in reality you'll mostly just be exchanging one set of costs for another. There can be a significant investment in tools and processes that enable a telecommuting company to operate efficiently. This is not something to be underestimated. A telecommuting company is not the same thing as a nontelecommuting one, with the only difference being that the workers are at home. In fact, if you just tell workers to stay home next month, you'll find out if your company is ready for telecommuting. It requires different tools, processes, management structure, and an overall different attitude.

As mentioned above, it takes a very well designed recruiting process to build an effective telecommuting workforce. That process is costly. It involves flying people to interviews, managing job ads all over the country, a multi-stage qualification process, and very deliberate training and orientation. All of it is labor-intensive. With nationwide telecommuting there are additional costs to comply with labor laws in multiple states, administering benefits, and handling different state income taxes.

To make telecommuting truly effective, a company needs to invest in a different kind of infrastructure. Internal e-mail systems and business automation software are not just luxuries; they are absolutely essential.

Knowledge at Art & Logic doesn't get communicated through random meetings in hallways; everything is very deliberate. We've been forced to become an intensely self-aware organization. All processes are documented thoroughly, and processes even exist to monitor processes.

All project-related communication is stored and organized on our workgroup server. Along with our standardized coding and project management practices, this makes it easy for people to join a project at any point. This allows project teams to grow, shrink, or otherwise change in response to the changing needs of a project.

Once an infrastructure is in place to enable telecommuting, it means that workers who are away from their home office can be just as much at work as if they were at their usual place of working, as long as they have access to that infrastructure. So, workers who need to (or want to) be in a different location temporarily (an airport, at a doctor's office, at a car service facility, in a coffee shop) can continue working.


Claim: Telecommuting is just a passing fad.
Status: There is no evidence to support this.

Telecommuting is here to stay, and it's just going to become more and more common. Consider these statistics (from WorldatWork Telework Trendlines):

• The number of Americans who telecommute at least one day per month was 12.4 million in 2006, 17.2 million in 2008. Currently, there are about 5 million Americans who telecommute everyday.

• In 2009, 38% of people who do not currently telecommute said that at least part of their job could be done from home.

• When asked about their interest in working from home, 35% were very interested, and only 21% said they were not at all interested.

As more companies implement full-time telecommuting positions, potential employees will increasingly demand it. Given a choice between two jobs, many candidates (at least 35% if the statistics are accurate) will tend to favor the one that allows telecommuting. Companies that don't offer telecommuting will lose out on good talent, especially on young, up-and-coming, technically savvy talent who are the most comfortable with online communities.

As more and more companies get on the telecommuting bandwagon, real information about it hopefully will replace the theoretical knowledge that is available now. Of course, having done this already for 18 years, Art & Logic will be in an even better position to understand the more subtle aspects of telecommuting in the future. So, some of the things that I don't know yet... well, just ask me again in another 18 years, and hopefully by then I'll know.

by Brett Porter, Chief Engineer

Many of the clients who we work with either have little experience with software development, or have experience with development, but not using an external custom development shop like Art & Logic. As a result, there can sometimes be misconceptions and confusion about what it's like to work with us on a project.

Estimates and Proposals

The first step in any project that we do will be to work with the client to determine the list of features that will be needed for the project to be successful. We can build this list in a number of ways, whether from an existing specification document, using emails and phone calls, sketches, or looking at existing versions of similar projects. Once we know what it is that needs to be built, we'll have one or more developers break those features down into a number of individual pieces that are as small as possible, and then estimate the effort that would be required to implement each of those pieces.

One problem that is typically seen on software development projects is that developers are often overly-optimistic about the amount of time needed to perform a task, failing to account for unanticipated difficulties or prerequisites that aren't readily apparent during the estimation process. One way that we compensate for this is by using an estimation technique called 'Pessimistic PERT'. For each item called out in the estimate, the estimator assigns three values; the best-case amount of time to complete the task, the most likely amount of time, and a worst-case amount of time. We apply a formula to those three values and calculate an 'expected case' value for each item. The sum of those tasks estimates, plus additional factors for other required activities like project management and testing the project add together to create a estimate for the project.

Staffing up the Project

Every project that we work on has people filling the following roles:

Account Manager: The Account Manager for your project is usually the same person who was your primary contact during the estimate and proposal process. He will be your point of contact for all matters relating to the business aspects of the project, and will remain in contact over the life of the project to ensure that everything is running smoothly.

Project Manager: The Project Manager is responsible for planning and managing the design and execution of the project. On small projects, the Project Manager may also be the entire development team, or he may be working as a member of a larger development team within Art & Logic. We find that projects are most successful when all technical discussions about the project are handled directly between the Art & Logic Project Manager and a single technical counterpart within the client organization. By requiring that all these discussions go through this channel helps ensure that there are no surprises from contradicting messages being sent between various people in the two companies.

Development Team: When assigning developers to the team for a project, we take into account many factors, including the client's schedule needs, desired monthly burn rate, how well-defined the project is, and what the ideal team size for the project would be. For example, a project that starts out with many unknowns will most likely kick off with just a project Manager and a designer, who will work together to develop one or more prototypes to help the client explore their real requirements. Once the required features for the project become more stable, we would only then assign additional developers to the team. We're able to react quickly with different team sizes as conditions warrant. A common misconception among clients is that be staffing their project with a larger team, the project will be completed more quickly; in software development, this belief is known as "The Mythical Man-Month" (see http://en.wikipedia.org/wiki/Mythical_man_month). We've found that small teams of highly skilled developers can finish projects more quickly and adaptively than larger teams could. All of our developers and project managers are trained to follow a common set of development practices, including our programming Style Guide (see http://www.artlogic.com/careers/styleguide.html) that make it easy to bring new team members in to work on projects already in progress.

Communication within the team and between Art & Logic and our clients is mostly done using a collaboration server called "FirstClass". This provides for each client a secure and private conference that's only visible to authorized client contacts and our developers. This conference is used to contain the complete history of all written communication relating to the project. It's much easier for everyone involved to be sure that details aren't being forgotten about when there's a single place to hold all discussion of those details.

Project Lifecycle

Once the project is in progress, we break the project down into a number of iterations, generally between 2 and 4 weeks in length. Each iteration is run as if it were its own little project, with these stages happening every time:

Preparation: The Project Manager and development team meet to go through the list of features and tasks that aren't finished yet, and re-estimate the work required to complete them. Typically, as we get deeper into a project, the requirements change at least subtly in ways that have impact on the number of hours required for the project. Just as often, as clients start seeing development releases of their project, new requirements are added to the project. By performing this re-estimation at the beginning of each iteration cycle, we have an opportunity to resynchronize everyone's understanding of where the project is, where it's headed, and our estimate of how much the remainder of the project will cost after factoring in new or changed requirements, our improved understanding of the known requirements, and our performance with regard to estimates so far on the project.

The team selects tasks from the list of undone work to be performed in the next iteration. This selection is done based on criteria like reducing any known technical risks (for example, if the project requires that we interoperate with new hardware or protocols, or uses externally provided programming interfaces that are still in development), creating any modules or subsystems that would block future work, or developing prototypes for client feedback as early in the project as is appropriate. For projects that are deployed to end users, client feedback will guide the team to work on features that will provide the most immediate value.

Execution: The bulk of each iteration is taken up with an execution phase, where the Project Manager assigns tasks to the development team, and the team does whatever work is needed to complete the tasks.

Transition: The end of each iteration includes any work that's required to verify that the new work done in this iteration was completed correctly (by testing) and cleanly (by performing peer code reviews). If the planned output at the end of the iteration was a release to the client, the release is prepared and delivered, along with release notes. In an ongoing project, this phase of the iteration will usually overlap with the Prep phase of the subsequent iteration, as the team works together with the client to plan the work that will be done next.

Long Term Relationship

In reality, most software projects don't really end; as users work with the first release of a software product they quickly begin identifying improvements. We take pride in the number of our clients who continue to work with use over many years and versions of their products to provide these enhancements.

We may be in a recession, but the rush to develop applications for iPhone, BlackBerry, and Google Android is stronger than ever. Art & Logic is one of the worldwide leaders in mobile application development. More than a dozen companies have recently hired us to develop their mobile apps. One of them was nominated for the 2008 Best App Ever Awards. View the recent project stories & screenshots.

The iPhone SDK is one of the most highly anticipated new platforms in years. Our developers are *very* excited about iPhone development, and have been eagerly learning the details of this new environment through our partnership with Apple. Fortunately, iPhone programming isn't a very big stretch from Mac OS X programming, and we've been developing Mac apps for more than 17 years. That may help to explain why our developers are so excited about this platform, and why we have already been hired to develop our first iPhone/iPod Touch SDK application!

We're not a hosting company, but many of our projects have hosting requirements of some kind. We currently manage more than 80 servers, including 25 physical machines. Until recently, all of these machines were located at the Art & Logic headquarters in Pasadena. With the company continuing to grow, we decided it was time for a better solution.

On December 27, we began working with a co-location facility located two miles from downtown Los Angeles. The new data center is equipped with two 10 gigabit connections, redundant HVAC cooling systems, inline UPS, a diesel backup generator, and 24/7 on-site staff. Preliminary testing shows ping times about 10ms faster than before. We're very happy with the new facility, and plan to move most of our servers over the next several months.

Art & Logic was hired by SRS Labs to develop an iTunes plug-in so they could bring their WowHd audio processing technology to Mac users. The plug-in (including a free trial version) is available here.

Today marks the 2nd anniversary of iTrain.com. In the two years that Art & Logic and iTrain have worked together on this site, it has grown to become the most popular website in the world for downloadable music for workouts. Art & Logic was responsible for all aspects of the project, including user interface design, layout, and construction; administrative tools, setting up e-commerce, testing, and project management. Most of the user interface is done in Flash. The server-side code is PHP/MySQL. There are multiple servers, with load balancing. Note that you’ll need to register to get a password to log into the site. Registering is quick, simple, and free at www.itrain.com.

Maretron is shipping N2KView, a boat engine (and more) monitoring program. Of course it handles most any raw NMEA 2000 data in a boat’s backbone, including J1939 engines via Maretron’s gateway. But an extra neat feature is that N2KView is actually a server, able to deliver the goods to all sorts of Flash clients, including that WiFi enabled phone.

Check out the N2KView screenshots (and maybe even buy one, if you’re a boat enthusiast!) at:
http://www.defender.com/product.jsp?path=-1|344|302025|750989&id=808159

Art & Logic is currently developing a retail sales application for mobile web users. One of the targeted devices is Apple’s industry-changing iPhone.

Art & Logic is growing. We now have more than 50 developers in our virtual office, throughout the United States and Canada, in addition to a small support staff in our Pasadena office.

If you’ve bought a widescreen plasma TV, you know that installation is more complicated than it seems. No one wants a bunch of cables hanging down the wall. You can drill holes and run them inside the wall, but what happens when you buy a new component? And what if the new component increases the total load to beyond the capacity of your mount? You have to take everything down and start over. Getting that Blu-Ray player is supposed to make your day, not ruin it!

Fortunately, one of our clients, Vantage Point, has developed a high end solution to all of these problems. The Evo System is a modular, flexible, patent pending system for wall mounting home entertainment systems. You can add and re-arrange modules as your entertainment system grows. Check out our Flash application, The Evo Designer, that lets you build and configure your own Evo system before you buy. Go to www.theevosystem.com and click on the Designer link.

Johnson-McCormick Technologies hired Art & Logic to develop the user interface and consult on the architecture of their rVibe music social networking/eCommerce system. The rVibe system brings together the best attributes of social networking systems (users can browse though the music collections of other users on the system, recommend tracks, albums, artists, or playlists to other users, and create groups with common interests). All content available digitally on the system is fully licensed; content that is not licensed for digital sale may be purchased on CD.

JMT wanted the user experience and rapid development that was possible using a web-based interface, but also wanted the ability for the client application to operate when not connected to the internet. Art & Logic developed a hybrid desktop/web application architecture, using an embedded web browser to display the user interface, but driving that browser directly from an application written in C++.

Art & Logic has hired John Palinski, an Oracle/SQL Server expert, to assist in tuning and optimizing database applications. John has an MBA, is an Oracle trainer, and is the author of Oracle9i Developer: Developing Web Applications with Forms Builder. He has also authored numerous articles available here.

PublishASAP hired Art & Logic to create an Illustrator CS3 plugin that will automate processing of “jobs”, each of which consists of a series of Illustrator files. The plugin manages the job workflow and calls JavaScript to do the actual processing.

Having just returned from vacation in Italy, I felt inspired to write about the parallels between cathedrals and software. Who knows; perhaps in the future people will look back on today’s custom software applications with the same admiration that I had for the Duomo in Florence. Here was a project that lasted hundreds of years, give or take a few dozen years if you count the gaps when funding ran out (sound familiar?). For a project of that duration, turnover was of course an issue; each time, the new project manager had their own ideas, often meaning that some of the previous team’s work had to be redone. But what struck me most of all was that the original design for the building called for an impossibly large dome; it was assumed that when it came time to add the dome, the necessary technology would have been developed. Talk about a risk item!

Art & Logic is expanding its development team: We’re looking for software testers. But in typical A&L style, we’re not just looking for people with experience in QA or test engineering; in fact, we’re mostly focusing on musicians and other creative types who are already using some of the world’s most complex commercial software as they produce music and video in their home studios. We believe that this experience combined with the right kind of “dogged approach” to finding and reporting problems could be just the right fit for our team.

One of our clients, SP Controls, just shipped a new version of their PixiePro Networked Room Controller. The NRC is a web-enabled device that controls A/V equipment (screens, projectors, DVD players, etc.) over RS-232 and IR. We were hired to create the web interface, which required AJAX, Java, and some tricky cross-platform JavaScript.

It’s always exciting to see a client’s product released to the market. Thanks to all the A&L’ers who worked on this!

Welcome to the Art & Logic blog!

Old Art & Logic news can be found in the news archive.