When dealing with project schedules, a dependency occurs when one task must complete before the next one can begin. Ideally you want to minimize the impact of dependencies on your schedule. One method is to schedule many tasks in parallel. If a developer is waiting for another task to complete, the schedule can give another task on which she can work.

Joel on Software says that dependencies are so obvious that he thinks that they should not be tracked. I agree that they can appear obvious to experienced project managers. But project managers are not the only people to use schedules. A new employee may want to use your schedule as a basis on which to estimate their schedule. Remember that your “customer” can also include your team and your company.

So, identify dependencies, document them and manage them with parallelism. Your project and your customer will benefit.

Lets face it. We are all different. We have different tastes and like different things. Wouldn’t it make sense that having choices would better please more people? In a recent article in the Linux Journal entitled “Separation of Church and Choice” the author made a case that choice alone is not a good reason to create software. While his article is churlish and bashes religion, it did make me think of an interesting question: Are too many choices in software bad?

The short answer is, of course not! I snicker when I hear about the supposed "tyranny of choice". Competition is good. The fact is that the strong will survive. The weak will adapt or find a small niche of supporters.

Having said that I see a case for cutting through the clutter. If you put together an integrated software system and plan to support it, then you will limit the number of supported choices. This makes fixing problems manageable. Also, provide a help system, e.g. a software wizard, to guide novice users by recommending common choices. It will keep them from becoming overwhelmed with new software.

Now, who wants some pie? What kind of pie?

How do you measure the quality of software? What distinguishes good source code from bad? Coding standards measure software quality.

Well-written coding standards define naming conventions. They also describe how comments document code. They discuss the layout of source code modules. They forbid the use of goto statements and self-modifying code. They may discuss the management of dependecies. In general coding standards draw on developer experience to produce guidelines that make code functional, readable and maintainable.

Your organization may bristle at the idea of a formal coding standards document. A coding checklist may suffice in its place. This gives guidance to the developer and may give a good discussion point for a peer review.

Speaking of quality, why isn’t there anything good on TV?

One of the lovely things about the Web is that you can traverse pages in any order you like. Sometimes it is necessary to remember information between pages. Think about Amazon.com’s shopping cart. As you find items you like, you can add them to the shopping cart. When you are ready to check out, the items selected are displayed. In order to remember information as you navigate between pages, a web application has to maintain ‘state’. In computer geek terms we say that the shopping cart application is stateful.

In order to remember your shopping cart items the application uses a server provided construct called a session. A session persists for a specified period of time across multiple connections and page requests from the same client. Using the session and a database we can store, retrieve and associate session data with a given user ID.

One mistake to maintain state is to use hidden form fields. This is a security risk open to an exploit known as cross-site scripting. It is much better to store such values on a database instead. You can use the session id as a key field. On subsequent pages the value can be looked up.

Another mistake is to try to maintain state by trying to persist data in objects declared in servlet code. This breaks down when there are multiple users. These objects are not thread-safe. That is, one user’s data can corrupt another user’s data.

So a good way to implement state in a web application is to use a database in conjunction with the session. By avoiding some common mistakes you can protect your website.

It has been my experience that short-term projects with a small team are the most rewarding way to produce software. Long running projects tend to suffer team turnover and burnout. A large team introduces new issues such a potential breakdown in communication.

Unfortunately not every project can fit inside of a three or six month schedule. It may be necessary to divide a project into phases. The purpose of each phase would be to fit into a short-term schedule.

The customer may be enthused by early versions of the software and may want to add new features. Also, the engineers may want to write geeky stuff that could help the project but whose scope is outside that of the project requirements. I recommend that you avoid this feature and requirements creep. Track the requests and assign them to later phases.

By focusing on short-term projects your customer will appreciate the quick turnaround of new software releases. Your team can take pride in their accomplishments. A successful project release will help motivate them as they start the next phase of the project.

Management might want to measure how productive their computer professionals are. One way to determine this is to count the lines of code (LOC) that have been produced. The term KLOC means ‘a thousand lines of code’. The thinking is that the more KLOC written, the more productive the team is. Lets take a moment to examine this more closely.

Do comments count toward the KLOC count? If not, why do you wish to penalize programmers for documenting their work? If yes, is a developer who writes a two hundred lines of comments accomplishing more than a coder who wrote fifty lines of code?

It may seem counterintuitive, but a programmer who writes fewer KLOC may actually be good for a project. Writing good software is a matter of managing complexity. An experienced developer will identify code that does the same work and will refactor the code to eliminate redundancy. So, eliminating lines of code is actually a good thing for a project. It helps reduce complexity which improves the time it takes to make code fixes.

There are better ways by which to measure productivity. One such method is to measure project hours. Project tasks are written down in a schedule called a work breakdown structure. Then an hour estimate is assigned to each task. Before a project starts the developers review the schedule and make any adjustments. Then developer productivity can be measured against how closely they follow the schedule.

Onions to the KLOC, orchids to project hours! Agree? Disagree? I’d love to hear about it.

Sometimes when you change code to fix a problem, a new error is uncovered. Sometimes the error was introduced by your fix. Other times the error existed but was masked by another error. When the error is found, you will want to compare the latest version of source code against old versions to see what has changed. A version control tool is invaluable for this task because it keeps track of the all versions of files.

Without version control two coders may attempt to change the same file. Changes can get lost. One coder might save his work over another coder’s work thus clobbering her changes. Some types of version control software work as a library. That is, they allow only one coder to check out and change a file at a time. Other software permits multiple coders to each work on private copies of source code and merges their changes when the code is checked in.

Team members can easily update their copies of all the project’s files to the current versions. Without version control software this process can be time consuming and tricky.

If you mess up code badly, version control software can revert any file to a previous version. This frees developers to try bold, daring ideas.

Version control software can allow projects to fork off the main baseline into seperate branches. In fact multiple projects can each work on seperate branches of source code. Once a project is completed its branch can be merged back into the main baseline.

Integrating version control software with defect tracking software gives a powerful tool to maintain projects. You can use identification numbers assigned by the defect tracking tool to identify code changes. Then it is possible to examine of the history of file changes to see that bugs were fixed.

I have been amazed by the number of places that attempt to write software without version control software. It is not strictly necessary to have a version control tool in order to write software. But I would not try to work on a project without such a tool.