L-P Huberdeau's blog

I was waiting in a lobby. Having nothing much to think about, all my attention was drawn to the very annoying fly trying to cross closed windows. Other than the annoying noises a fly usually make, this one almost made a symphony repeatedly banging itself into the surrounding windows. I only sat there for around 5 minutes, but I almost turned crazy. It reminded me of that time where the printer repair guy had to install the new network printer. The guy had absolutely no idea of what he was doing. Even if he was sent by the selling company as the top-notch technician, the guy would simply go over the installation/uninstallation steps trying all setting combination until it would work.

Of course, the smart way would have been to stop for a minute and read the software’s documentation, which he had in a 3 inch thick binder. He didn’t do it. Just like that fly, he kept banging himself to all windows until he actally go to try the door while it was open. But I’m not blaming the fly. It’s not like it knew what a door is.

The impressive part is that he actually carried that binder around, even if he had no intention of reading it at all. Why he printed it out in the first place is an other of those mysteries. Maybe having that documentation made him look more serious to managers, or maybe he feels more secure with the answer to all his questions close to him.

Without having the pleasure to observe a printer repair technician in a typical office environment, you can observe the similar phenomenon in universities. It’s the same thing, but with larger proportions. All the students buy the reccommended book accompanying the course. Some never actually open it. They carry it around the whole semester in case the professor explicitly asks to open it during a class. Many sell it brand new a few months later, but some simply place it on a shelf (shelves filled with books you never read, can you think of a better way to look smart?).

I guess we all have our moments where we know nothing of what we’re doing and still keep trying. At least, any self-thought programmer had some moments in early days when trying to figure out the logic behind the constructs. The documentation is never that far from reach, but having to read it is an effort. With some luck, that next try will save all that reading time. I still happen to do it when trying to figure out which one of padding or margin will give the appropriate spacing in an XSL-FO table. Fortunately, I don’t have to do it that often. One day, I will try searching for that nice diagram that explains it all, print it and hang it straight next to my monitor.

Two years ago, I discussed how translation could be handled in collaborative websites to ensure the different versions could be kept synchronized. After all this time, still no working implementation are available. As far as I know, no effort has taken a specific direction. The topic is always discussed around, but only more problems are raised. The topic was brought back to me yesterday night and my old post was quoted, I didn’t even remember I had it written.

The issues remain the same. Changes occur from everywhere in the documentation and there is no way to track these changes and make sure they are applied in all translations. From a user’s standpoint, there is no way to know if the translation he is currently looking at is up to date. The only way to find it would be to take a look at the master version and see if there is any more content. If everyone could read the master version, we wouldn’t have to care so much about translating everything.

So far, all the solutions I heard about are based on having a master version, which would ideally change from one language to an other as progress is made. There seems to be a global agreement that it’s the only way that it could be done. It sure is a solution, but it somehow removes the collaborative aspect we were trying to achieve in the first place. The structure you end up with is a sub-group working on a master version and improving the content, and the rest of the world translating. Until everything is translated, there is no way to make any improvement on the content, unless you can become a member of the current master sub-group.

That solution considers that all the translations will be in sync at some point. If the website is translated in two languages, this is likely to happen with enough efforts from the translating group. With three languages, it might still be possible, but for anything above that, I seriously doubt it. The only way it could happen is if a complete content freeze was called until translations were completed, but this really goes against the idea of collaborative development.

I think the solution is to accept that the versions will no be in sync and to refuse any form of master copy. Translations are a way to reach more people, but it’s not acceptable to slow down development just to wait for a minority, and reaching these people is not enough if you can’t allow them to contribute to the whole.

According to me, the way wiki applications currently handle revisions is slowing down this translation process. The initial version is 0 and it increments with any improvement. With each revision number, the modifications should be applied to the translations and revision X in English should match revision Y in French. If a modification is made in the french version, it should still be possible to match the revisions in both translations. If two concurrents modifications are made between change propagation, you’re busted. Revision numbers are way too linear to work in a collaborative environment.

Wikis work well because of their simplicity and the fact that they keep an history of all revisions is what makes them so effective in a collaborative environment. To the user, being able to see the exact changes that were made since the last time they looked at a page is really useful. Thinking that a page can be compared to an other “equivalent” page the same way it can be compared with it’s own history is a big mistake.

Getting rid of the master version

To get rid of the master version, you need to accept these revision numbers won’t match with each other and rely on an other technique to keep track of the changes that need to be applied. Each change has a purpose and an impact on the content. Let’s consider a situation where changes are made on concurrent revisions. For simplicity’s sake, the initial version was translated in all languages and the content matches initially.

In the situation above, modification B was made in the English version and will eventually need to be integrated in the 3 other versions. The error in the initial content was noticed simultaneously by two different contributors. The correction will need to be applied in the two other version, but a way to indicate the two corrections were actually the same thing is needed. Modification D is similar to B, but I wanted to place the focus on the fact that English is not a master version.

When looking at the English version, the users should be indicated that the German version has a piece of additional content. On the other side, the users looking at the German version need to know that related links have been added and that a correction was made on the content. If the German user knows enough English to translate and decides to do so, he should be able to see the differences that were applied by the specific changes and perform them on his own translation. When making the revision, a way to indicate that the change has been integrated is required. This way, the next time a German user accesses the website, no missing information warning will be given.

After the changes, the revision history of the German version might look like this:

1. Initial version translated from English [A]
2. Correcting a typo
3. Adding information [D]
4. Applying correction and adding related links [B, C]

As indicated by this hypothetical revision history, multiple changes can be added in a single revision, and not all revisions create a change. As I mentioned two years ago, not all changes are relevant to other translations.

Using this technique, all versions can evolve independently and still give enough information to the translators to complete the information with the evolution coming from the other languages. As a side effect, translators who do not understand English can easily get a list of all other translations which integrated a given change, and can see what were the differences applied to perform this change.

In the case of the correction made at two different places, it’s not really possible to determine automatically that the two changes are actually the same. In a perfect world where the second contributor two perform the change understood the first change, he could simply mark the change as integrated, but if he doesn’t, some translator will eventually come into play and will have to sort out this confusion. A that point, there needs to be a way to indicate that both changes are the same and two options are possible: create a relation between the two changes to indicate they are equivalent, or destroy the later (or mark as obsolete) and link the revision to the prior change.

Categorizing changes

In the table above, I used a label and a description to identify the change. The label was a simple way to refer to a change from the text and the description was to give a meaning to the example. What do we really need to know about these changes to be integrated? The type of change (correction, improvement or new content) could be helpful, but alone it’s not enough to help the translators identify the change they are trying to integrate from a diff of two revisions, especially if multiple changes are made in the same revision change. In the example above, I considered multiple changes could be integrated in a single revision, but I see no reason why two different changes couldn’t be created in a single revision. Differentiating those changes require a powerful diff tool to split the changes and create a unique entity for each of them. If multiple changes are made in a single revision, the one thing you don’t want is to have your translators confuse these changes and mark the wrong change as integrated.

It seems like a description of the change is required to do this, but that brings some kind of recursive problem. In which language do you write that description? I don’t think there is an easy solution to solve this one. It could be possible to disable the multiple change per revision functionality, but since this is about a collaborative environment, there is no way of making sure the contributors will follow the guidelines. You could end up with single changes that actually contain multiple other changes, which will be a mess to track and integrate.

Now, how do you deal with faulty contributions? What if someone adds information that is completely wrong? There are many ways to deal with this. In a small community or a highly hierarchical one, you could have a person or comity to approve the changes before they are made visible to translators or you could install a rating system where the users or translators could indicate if the change is good or not. A bad change would eventually have to be removed from the version it was added in and be marked accordingly.

In two years, nothing really changed in this field. It will probably take a very long while before a real solution is applied. The main problem is that there is probably no one solution to fit all cases. Different project sizes and cultures will require different solutions. What I propose here is a technological solution, a way of organizing the content. Just like wikis, it will depend on the way people use it. The management of the translations is based on meta attributes added to the content and revisions to allow relations to be made, but if these relations are not applied correctly, there is no way to get it to work.

Wikis work because they are extremely simple to modify. Adding a system to manage the translations make it not as easy. Two years ago, I proposed to tag the changes based on their types to adjust the notification level. This new proposition asks a lot more from the users. Not only do they have to tag their changes with a type, they will also need to describe the purpose of their changes and indate what changes they integrate. It could probably be done without describing the changes, but I doubt integration of the changes will be as easy without these messages.

Like most developers out there, I have to write some user documentation once in a while. After a few weeks of intensive development, a few days have to be spent documenting the new features. It just has to be done, otherwise I will get stormed with questions once the beast is released. While I write the documentation, a few empowered expert users already begin to use it. Documentation probably wouldn’t take so long to write if I didn’t have to listen to all those comments.

Writing user documentation takes a lot of time, but it might be worth it for the software quality. I write the documentation based on user tasks and the expected behaviours of the system. The process of documenting itself forces me to perform some validation. Multiple questions come up when you attempt to write down words that end users will eventually read.

• Is the term used appropriate? Is it consistent with the rest of the application?
• What is the data input format exactly?
• Is there anything that could be unclear?
• What are the exceptions? How can they be differentiated?
• I know how the information is used by the system, but what value does it add to the user?

Most of these questions can be answered by testing and peeking at the code to verify the exact rules implemented. For others, the early adopters can be of a great help. They already have a global understanding of the system (mostly because they were involved early in the development cycle), but they know the exact details and can offer this very first impression in an articulated way. The goal is to find the picky one in the group. While they are mostly annoying when the application is in production and you moved to the next problem, during this phase, they provide the comments that have the most value.

The element that makes the largest different is probably the act of documenting itself. The perspective moves away from code, design and data. By focusing on the user’s process and the tasks to be performed, you can focus on what the real needs are. Examining the tasks was probably done very early in the development, but when you write a few hundred lines of code in a day with the clear objective of delivering features, these user-oriented thoughts often slip away.

As you get a new perspective, you get to understand what matters the most to the users and can write something that makes sense. Most of all, you get to see what does not quite make sense in the application. Those minor interface improvements suddenly appear. Sometimes, changing the order of a listing, changing a label or even adding some spacing can improve usability, and substantially reduce the amount documentation to be written.

I noticed the developed software is a lot more polished after writing documentatiobeneficn today, but when looking back, it happened in the past as well. A few years ago, I contributed an on-line spreadsheet to Tikiwiki (which was surpassed long ago when google-style pastel-colored ajax-powered applications started to appear). The interface was always a little clunky, while I could generate graphics out of the data, I was probably the only one who ever got to make it. At some point, I was asked to write documentation. When I got to write it, I made a few commits on CVS just to simplify the documentation I had to write. It’s not that good of an example, because TikiSheet’s interface is still the worst spreadsheet interface around (some damage can’t be undone so easily, and it’s not like I had that much time to spend on it anymore).

Some say documentation would not be required to understand how to use an idea application. Unless you have a few usability experts working on the project and people with perfect knowledge of the user tasks, along with a clear vision of the final product, it probably can’t be achieved. Software improves as it gets used. I think writing documentation of sufficient quality can be a good first step to improving the interfaces.

Since, like most programmers who don’t have a complete crew of experts to support the development, I have to place some focus on development and get some work done. Spending around 20% of my time writing documentation, and validating the application at the same time, sounds like a good compromise. As a benefit, I can release a more polished application to the end users.

This would probably not be possible if the documentation was written by anyone else than the developer. It could be possible, but only if the developper is open to comments during that period and ready to make the small insignificant changes. Of course, this is not likely to happen. In fact, one of the only reasons why I actually make those changes now is that it can potentially reduce my documentation workload. It’s also because once I spent over an hour writing documentation, moving to anything else, including apparently insignificant changes, is a good option.

What I really am wondering about is if writing developer documentation is all that useful. If the simple fact of writing documentation places a focus on quality, is it really benefic? I remember assignments in the first design courses at university when we had to write reports to explain our design decisions and the patterns used. Of course, it was for educational purposes, but the design that came out of those assignments was so pure and flexible that it would make it more complex and unusable. Writing developer documentation places the focus on technical aspects. I have no doubts it can improve the design as they teach in the textbooks, but is it really what you want? Think about it in a different way, is it really what the person sponsoring your development need?

These statements probably classify me as a software engineering heretic, but I really don’t think code needs documentation. If the application’s design is consistent, the developers that follow only need to understand the base layout to find out how to perform modifications. If each component’s design is close to perfection, but every component has it’s own specialized flexible design, the learning curve ends up being much longer.

Placing the focus on object oriented design tends to create applications that are far too expandable. Concepts are generalized even if they are not likely to be used in the future. If a single concept is forgotten (you know the forgotten concept is the one that will be needed, right?), the whole design is only making the modification harder. Not only you waste time designing, but time was made implementing extra layers of complexity to make every single class absolutely simple. Then the relations between all those classes and objects have to be documented. What does it take to document an object model? A whole lot more than text. It takes graphics and diagrams. To get these done correctly, you need specialized tools. In the end, it takes a lot of time and does not provide that much value.

Face it. No one likes reading documentation. I don’t know many developers who willingly grab a software’s documentation an read through it before attacking development. Documentation is the fallback plan. It’s the fallback plan for the users who can’t accomplish their job by simply trying the application and it’s also for the developers who don’t see where to plug their new features. The reason why end users fall back to the documentation is that they end up being completely blocked. Applications developed for end users are a lot more restrictive than a programming language. Programmers are likely to destroy a huge part of you well planned design before they end up being blocked. They might never even notice there was documentation written in the first place.

The goal of a software developer should be to provide a solution. Focus should be placed on the results, not on internal details. Writing user documentation allows you to validate user requirements, improve the interface provide a fallback plan if you interface’s simplicity fails.

In measurement, dysfunction is what happens when, by measuring a certain aspect, you degrade the overall performance of your process. While this kind of problem is not likely to occur when you perform measurements by your own will, dysfunction has been observed in many occasions when measurements are linked to evaluation. When salary is bound to a performance indicator, employees might be tempted to trick the measurement to get better ranking. Even out of the business/engineering context, think about all that blog spam to get better ranking on Google. That’s dysfunction.

When you think about it, education has a lot of dysfunction problems. Exams are just a way to measure the comprehension, and the measurement result is bound to evaluation and ranking. The problem with this dysfunction is not about the students cheating, it’s with the exams themselves. For disciplines where truth exists, such as mathematics, evaluations make sense. Either you have the right answer or you don’t. The problem is that there are very few disciplines where the evaluation can be 100% objective. Yet, all of them use a similar measurement system to assign grades.

Software engineering is all about subjective answers. Of course, I’m not considering an assignment where a piece of code has to be written. Two types of evaluations can be made.

• Open questions where any answer can be right depending on the context it’s taken.
• Narrow questions where only those who spent time memorizing lists of elements can succeed.

Both cases have their own dysfunctions. In the first one, the results will be entirely subjective. The one correcting is simply not allowed to give 100% to everyone. The lucky ones will either be those with an opinion matching the correctors opinion, or those including as many concepts as possible into the text. Getting the same opinion as the teacher is fairly easy. All you have to do is attend to the classes and repeat everything said when the evaluation moment arrives. Including as many concepts as possible generates a solution full of buzz words and no real structure. Sadly, those really thinking about an acceptable solution rarely fit in the lucky group.

I once saw a teacher who attempted to evaluate open questions based on if it made any sense. It was a complete disaster. When a subjective criteria is evaluated, the are no evaluation grids, no way to prove it was fair. As a result, lower grades complain until they are actually part of the higher ones, or until everyone has the exact same grade (you can actually hear those same people complaining later about the grades being too close).

On the other hand, narrow questions can’t evaluate comprehension at all. It does not even require attending to a course. All you need to do is take a full day to memorize everything highlighted in the course slides.

These are examples of dysfunction. I guess anyone who studied long enough can recognize some of these student types. The worst part is that if you want to compete against them, you actually have to play with those rules. In the end, what do you get out of it? Engineers that can’t think by themselves, copy solutions straight from books. I once heard a complaint about modern electrical engineers (or what is mechanical?) not being able to solve problems anymore. All they would do is perform calculations. Looking at the state of dysfunction in education, this is not surprising.

There is no way I can think of evaluations can be removed from education. Without evaluations, you would get a diploma after sitting in a classroom for 4 years, with no guarantee at all you learnt anything (which is not really different from the current situation, but that’s not the point). I think the solution resides in applying the engineering concepts in evaluation as well. Open questions are the only way to verify global understanding of the concepts. Knowing the details is not as important as knowing where to find them. To make open questions successful, a few steps have to be taken.

• Inspect evaluation material before handing it out to students.
• Test the evaluation on a sample group of students.
• Use redundant correction on critical evaluations.
• Request independent validation of the results before releasing the scores.

Important artifacts part of a software projects should be inspected to make sure they are correct. In the same way, evaluation artifacts should be inspected to ensure that no ambiguities remain, or as few as possible, remain in the final products. I’ve seen situations where the primary discussion leaving an exam was “What was question #3 all about?”. You could ask as many people as you wanted, you would get a different interpretation. This is actually when the question appears to be clear enough so that no one complains about it during the exam. I got to cross a few unreadable questions as well, containing typos, duplicate words, missing punctuation, …

The best usability test is always to get a real user to sit and try it out. Why not do it for evaluations as well? It could allow to remove the questions that are too easy, those that are completely impossible to answer and get a well balanced exam that can be challenging.

When the nature of the exam is subjective, having a redundant correction can help raising the confidence level of the final score. For the students, it’s an indication that the result is not based on a single person’s opinion. For the correctors, it’s a protection against those that would complain to get their grades up. In a least-critical evaluation, having an independent auditor to double check 10-20% of the copies could be enough.

Of course, it takes time, and most professors probably don’t like the idea of stepping away from their research projects to worry about the 1st cycle students, but if they ever want the result of their studies to be applied, they will need to make the students believe in their discipline. I don’t know of many students who applied many of the “state of the art” concepts exposed in the classrooms during their internships (except maybe those related to design). Providing quality evaluation that force to understand, and promotes understanding, instead of memorizing might do a difference in the behaviour of software engineers in the industry.

I believe any developer can deliver a bug free application. No need for unit tests or any kind of heavy-duty techniques as written in the textbooks. Applications always work on the developers machine. What kind of fool would deliver, or mark as completed, something he couldn’t get working? The problem is that there are many steps between the end of development and the production use by the end user. One of these major steps is deployment. There is always a tiny dependency on a library you forgot to think about, a minor version change in a library that should be compatible, but appears not to be, a small configuration flag you forgot to transfer. These errors are always hard to find, and mostly make you look like a fool.

Once you get past that terrible deployment phase where users reported a bunch of “bugs”, which are in no way part of your new system, they start having improvements to propose. Academics will tell you it’s because you made a poor job at collecting requirements. I consider improvement requests are part of the normal development cycle. You can dig into requirements for months, obtain a concensus on what has to be developed, you will still end up with tons of requests. Requirements based on paper and static needs are abstract. Most non-technical staff have hard times visualizing the final results out of these cold terms, even if they were inspected a dozen times and are completely unambiguous.

This is where the strength of the Agile methods lies: providing users with concrete, working products on which they can comment. As long as, when you encounter one, you notice the fuzzy spots and the assumptions made during the development, you can design in consequence. Leave open doors for future modifications. Don’t lock youself in a static framework. Your design needs to be as agile as your development cycle.

Real problems also come from improvement requests. Everything always seems to be urgent, and it can sometimes be. There is an urge to perform the change and place it in production. This is where real bugs appear in the system. If the change is made too fast, changes are that it will be incomplete. Components of the application that should have been modified to reflect the change have been forgotten. If you’re lucky, the user will report the new problem fast enough and you will be able to link the problem to your recent change.

If you’re less lucky, the forgotten component is part of an infrequent process, a conditional one, or worst, invisible. The problem may only see the light weeks or months after. That’s when it becomes a major problem. At that point, you might not even remember the change was made. If the behaviour was invisible, you’re probably stuck with some corrupted data for which you will have to write a correction procedure. Do I really have to mention this is something you want to avoid?

Process-driven world uses impact analysis to determine what is affected by the change. Since they have a bunch of fancy tools to perform the traceability of their well defined requirements, they only have to perform a few clicks to get the list. Of course, it considers the requirements database was kept up to date and all the links are valid. Once they have the list of changes, they can perform an estimate, submit it for approval, write some more documentation on the way and perform the change.

Impact analysis can be applied in a smaller context where not so much documentation is present, and where not complex toolchain is integrated in the development cycle. The person who wrote the application is probably in the best seat to determine what are the technical impacts of the change. It can be done very quickly, within a few minutes.

When I got in the office one morning, the project’s sponsor came up to my desk to ask, among other things, what were the progresses on the project. The situation was a bit like this.

• Mr Sponsor: So, how is the project going?
• Me: Quite good so far, only a few approval steps are missing, along with the public display of information.
• Mr Sponsor: Let me grab a copy of the ISO procedure supporting this application and we will review it together

As we were reviewing the procedure to see if all the steps were covered, or if the dating procedure had to be updated, a coworker (non-technical) and potential user, jumped in the conversation and starting to propose changes.

• Coworker: This looks good so far, it will remove a lot of redundancy in my work.
• Mr Sponsor to Coworker: How do you perform step X at the moment? The application reflects what is in the procedure, but it seems awkward.
• Coworker: Right now it’s only a paper form, and I only fill it afterwards because the format forces me to, but if we could pre-fill it in the preparation step, it would definitely make sense.
• Mr Sponsor: Sounds good, I’ll make sure the procedure gets updated.

The conversation went on for around 10 minutes. As they were speaking to each other, I was sitting back taking notes, making a list of all the small changes that were required. Since not all of the discussions were concerning changes, I took some time to list the changes to the database schema and affected interfaces. By the time they were done discussing, I had calculated the amount of affected function points and calculated the estimated schedule impact. We reviewed the list of suggested changes and impact analysis was almost over. Before performing the actual changes, I performed a few greps in the code (as I said, no fancy tools required) to verify if I missed anything, and it was good.

By the time I was done with this, the coffee brigade was passing by, meaning the whole story took under 20-25 minutes.

Of course, this story applies to an application that was not currently in production, so I did not have to worry about loosing data or such. As I worked on that specific project the day before, concepts were still very fresh in my memory and I didn’t have to remember them or think too much about those hidden dependencies. Still, the impact analysis is a valuable tool. It forces you to stop developing for a minute and think about what the consequences are. I usually transcript the changes from my note pad to the wiki for future use. The list of changes can then be used as a checklist to see if all the required changes were applied.

On larger projects with contractual agreements, things might get more complex, but you can apply these things in day to day development without much effort.

Obtaining an estimate from collected data is easy enough. The FORECAST() function in OpenOffice.org will perform linear regression on a set of entries, which should be good enough if you data has any kind of correlation. All grouped together, it might not be that easy to find a correlation between the different projects, especially if they are of different nature or written in different languages. This entry will present techniques I used to divide my projects to find correlations.

The International Software Benchmarking Standard Group (ISBSG, pronounced ice bag) determined that the most determinant factors affecting the total project costs per function point are:

• The programming language
• The platform
• The size of the development team

While they have some data to support these elements, this is far from rocket science. Everyone knows that PHP is faster to write than C++, development cycles are slower on a mainframe than on PC and communication issues slow down teams. The only elements that you should care about in this list are the two first ones. As the technique I used is based on a personal process, team effort is not considered. The only way it could reflect the data is in the noise it generates in the non-task time.

You probably don’t want to mix handheld device application development with web development. Even among web applications, an intranet application can probably not be compared to a public application visible by thousand of users. Even if the technology is the same, the expected quality attributes simply cannot be compared. A public application requires much more attention to interface details, security issues, performance and so on, while the intranet application used by a dozen of trusted users can cut short on security (as long as error-proof validation is done) and performance issues. Even the user interface does not require as much attention as you can provide training as needed.

I know what you’re thinking. You could use a database to store your project information and use tags to assign the quality attributes and use these to select the projects that are going to be used as part of the estimation data! Stop! You don’t need anything complex. Chances are your business is evolving in a niche market or is working on similar types of products. If 80% of your projects fit into a similar category, there is no real need to split projects in dozens of subcategories. In my case, most of my development fits into the intranet type of application. I decided to ignore that other 20%. I simply don’t measure it. I have 80% of my projects in a single group, and the other 20% is divided into multiple small groups where only one or two projects can fit. Measuring these projects simply feel like a waste of time since I will probably never use the data.

If among very similar projects you still can’t reach a correlation, I can think of 3 different reasons. There are probably more.

• You are not consistent in the counting technique
• The counting technique is too simplistic or not well adapted
• Your output is simply not regular

The two first issues can be solved with time. Try counting on more projects, try with different techniques. It does take time, but what good can you do on a Friday afternoon anyway? The last element might happen if you are new to the development environment. There is nothing more you can do about it. While measuring is a good training for the future, it won’t help you at all. You simply need to learn more about the environment, get used to the behaviours, error types, and all those things that make the difference between a junior and a senior programmer. If this is your case, you are probably better off measuring the defects you generate and detect, along with their types. While it does not appear to add any value, it will help you identify your weak points and help determine where to focus efforts and what to look out for when problems occur.

The COSMIC-FFP method discussed in a previous entry indicated that function point additions and modifications should be counted together. I do the opposite. Both my estimation table and my time entry sheet have distinct columns to track additions and modifications. Modifications tend to be much shorter than additions (by a factor of 3). In a perfect world where all my projects would have the same ratio of additions and modifications, I would not have to make a distinction. Some of the projects are modifications only of existing features while others are almost completely new development, with a few integration aspects (which I count as modification).

I found this separation after a few projects. At some point, I was tracking 3 columns: addition, modification and integration. I merged the last two as the performance indicators were very similar. You can find information like this by carefully looking at the data and comparing it with other projects. When you have 4-5 projects, you can do this easily. Pay attention to the distance between your final value and the estimated one as a percentage and ask yourself why it’s different between two projects. It may be because you wasted half a day on a single problem, or it might be that the two projects are of different nature, such as containing more modifications of existing features.

I also noticed that the estimates tend to be more accurate when the project size is significant. Small projects that only span on 1-3 days tend to be inaccurate. Performance is a lot more about human issues than technology. Projects that span on short periods do not get your average performance, they get your performance on a specific day. If you suffered from insomnia over the night, it will affect your performance on that day. A two day project is likely to be delayed significantly by a single bad day. On the other hand, a two week project will easily absorb that bad day.

The downside of estimates is that you only know if they were good at the end of the development, but once you got a few estimates within 5-10%, you can feel more confident about them. I did say 5%. It does sound unrealistic when all those books mention terrible fiasco stories where the final product doubled the initial schedules, but it’s a completely different story. What I do here is programmer-centric micromanagement. I plan a few weeks ahead at most. I don’t deal with contractual issues, external relations, communication among developers, poor requirements, and all those things that could get a project to fail. The estimates are very accurate because the data is very specific. It’s not about general PHP performance, it’s about my own performance.

I first moved from TikiWiki to DotClear because all I wanted was a blog. Now, I’m switching to WordPress, hoping that all those comment spam problems will end. With barely anyone commenting on this blog, I still had to filter out the spam, and there was no way to perform batch actions on it. WordPress has a much larger community, which offers a vast anti-spam arsenal. Plus, the bundled themes don’t have any hard-coded strings in them. DotClear was a very good application, and solving the problem was probably possible, but switching to WP was simply easier. It even imported all my posts.

Now the only problem I have is that the generated HTML does not validate. Seems like there is an issue with the format of the imported comments. I might decide to solve this problem at some point. Until then, sorry W3C.