How much detail in requirement?

I mentioned that over the course of twenty five plus years, I've tried nearly every development process you can name. In my experience, I find that projects tend to break down at the start. Yep. Failure is built in into the project during the requirements stage.

Requirements are written in varying detail. During my tenure with DoubleClick in 2000, we had initiated a project for the advertiser side of our industry. In my ten months with the firm, the document was never finished. The last time I saw it, it exceeded 300 pages. We appointed a steering committee to oversee the project and they would debate the document endlessly. And the result of the debate? A bigger document.

In short, the entire exercise was useless. In parallel to the requirements fiasco, an engineering team was already well into the project, virtually ignoring the written requirements. I have seen this practice of over doing requirements at several firms, including DoubleClick, Information Builders, and Ameritech. In most cases the resulting document is either too large to be useful, or is ignored by the developers.

Of course the reverse is often true too. In fact, the reverse is probably much more frequent. For example, my team recently received the following requirement for a component of a new product:

"Management reports – using multiple selection criteria, produce reports that track turnaround time and other metrics."

Thing about the number of questions that are opened by this simple one sentence requirement. What reports? How many? What columns, rows, sorting, totals? What selection criteria? What is turnaround time? What other metrics? In fact, this requirement tells a developer nothing. There is absolutely nothing the system architect can do except return to the business analyst and ask questions. To make matters worse, the business analyst believe he has provided a useful document.

Then there are requirements that mask the business need in technical details. Some might read something like:

"Add a column to the x table to hold a flag. Display the flag on the detail page. When transactions are received for records with the flag set to 0, ignore the transaction."

This might look like the appropriate middle ground, between the extreme examples illustrated earlier. But it's not. The business analyst has interpreted the business requirement and supplied a solution. Although many business analysts fancy themselves as system architects, I have yet to meet one who is better than the engineer. What is the requirements above? A method of disabling master records? A method to manually override batch operations?

The plain fact is it hard to write useful requirements. And a project with poor requirements is destined for delays and cost overruns. If you wish to keep your requirements meaningful, stick to the following rules of thumb:

• Describe the business need (not the technical solution)
• Keep it brief (it a single capability takes more than a couple pages then your too verbose)
• Describe everything (if there are four reports, describe each in with their own requirement)

When you avoid the pitfalls from poor requirements, your project will be constructed on a solid foundation. The chances of success are will be far greater.

More reading for fun

I read two books recently and they were both pretty good. The first is American Creation and the other is A Tale of Two Cities. Yes the time period is similar in both books, but that was merely a coincidence. I don't have an express interest in 18th century history.

American Creation introduced me to stories about our history that I found intriguing. I had held a belief that the founders were mostly united through a common enemy and purpose. That belief didn't make sense and the stories in American Creation highlight the difference of opinions and approaches that form the basis of our nation. Themes trumpeted by Washington (strong central government) and Jefferson (sovereignty of the states) echo in politics today.

I found A Tale of Two Cities surprisingly good. Sure, I was familiar with the opening page..."the best of times...the worst of times." I had even attempted reading it when I was younger. This time, though, the story had me riveted. Yes, you have to adjust to the flowery language of Charles Dickens, but the story is very suspenseful. Plus there is plenty of violence, intrigue, and romance.

What Were They Thinking?

Here's a book that you can pass on. What Were They Thinking is management dribble that either states the obvious or makes poor conclusion. I've seen the reviews on Amazon and must admit that I disagree. In fact, I think this book is dumb and was very disappointed. I picked the book up based on a magazine review. I didn't feel the anecdotal examples sited by the author truly supported his conclusions. I could easily come up with examples of my own that would refute his claims.

SDLC

Agile. Waterfall. CMM. Spiral. Test Driven. Blah, blah, blah. I believe I have researched a dozen software development methodology and have tried many of them in practice. Unfortunately I have yet to find one that works. One that combines rapid development with high quality and delivers projects within their targeted timeframes.

I suppose if it was easy, then there wouldn't be entire shelves at Barnes and Noble devoted to it. It it was easy, then everyone would deliver with great success. I'm becoming convinced that no single methodology is portable through development shops. And that successful SDLC (System Development Life Cycle) is a painful trial-and-error process that adopts aspects of several disciplines.

I've tried the standard waterfall. It generally has two problems. First, it is nearly impossible to completely define all the functions of a system prior to providing any code. And second it is very difficult to prevent scope creep.

In the first case, a business analyst has to be imaginative enough to define all aspects of the system. Then she must be able to accurately write these into requirements that are understandable by developers. I've never seen this done well. When overdone, the volumes of requirements become impossible of shift through, when underdone entire aspects of logic are left undocumented.

Waterfall project tend to be very long, running months or even years. This causes the inevitable panic when business analysts realize a pet feature is not included. The panic often results in scope creep, which in turn causes the project to run longer.

We've tried incremental methodologies, such as Agile too. Ok, you say, Agile isn't a methodology, but a class of methodologies. But does anyone really implement strict Extreme or Scrum or EVO?

Regardless, Agile methods have their built-in weakness too. For instance, how do you know when you are done? Or, as in the case with my current projects, resources get diverted into new critical projects, leaving others unfinished.

When it's all said and done, some hybrid method seems to work best. Concrete, but overlapping, phases are necessary for project management. Within each phase, iterative cycles with feedback have great benefit. Who knows, maybe I'll develop my own methodology, and then write a book (that no one will read).

Headhunters

Has anyone noticed that recruiters work harder when you're hiring than when you are looking?

Just read a great book

Ok, while not exactly a summer read, I found Made to Stick is a great book. The book is a must read for anyone struggling to get their message out. The author's method is based on their academic observations which they have summarized with the acronym SUCCESs.

SUCCESs is easy enough. It stands for:

• Simplicity Stripping an idea to it's core, without turning it into a soundbite.
• Upexpectedness Grabbing a person's attention.
• Concreteness Making the idea understandable.
• Credibility Getting people to believe the idea.
• Emotional Getting people to care about the idea.
• Stories Getting people to act on the idea.

Whether you agree with their classifications and conclusions or not, you will find incite in their examples.

What happened to OOP?

When recruiting engineers I always start with a discussion on object oriented programming. I try not to completely surprise the candidate, so I always list the four topics: abstraction, encapsulation, polymorphism, and inheritance. Then I ask the candidate to define each term, and tell me how (and why) it is used in real world situations.

I have to admit that I am amazed at the percentage of developers who do not know the fundamentals of OOP. Even developers coming right out of school struggle with this conversation. This despite the fact that most of our entry level developers are coming out of Masters of Computer Science programs.

It has caused me to wonder if OOP is coming out of favor. If this is the case, then what is replacing it? Gang of four patterns? Something else?

You can say I am an old school developer. I learned to code when the style was structured programming. There was no concept of OOP when I earned my Computer Science degree. I was introduced to OOP several years later, when building my first applications for Windows. I immediately saw the maintain beauty of maintaining a single piece of reusable code, this was a logical extension of function libraries.

OOP was a natural evolution of structured programming, and yet I was amazed at the number of my colleagues that did not make the switch. And those who didn't were relegated to mainframe jobs and maintenance of legacy system. The best engineering opportunities were given to those who were evangelists of object oriented programming.

But as Internet development took off during the first dot com boom, a couple of trends started. One was the adoption of Visual Basic, and the other was design patterns from the gang of four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides).

In my mind, Visual Basic is and was a horrible trend in the practice of software development. The language, especially in its' early versions, encourage poor programming practices. And Microsoft's CASE style designer tools only exacerbated the problem. Departmental developers from corporations picked up the easy to learn language, and churned out applications that were impossible to maintain. Although recent versions of the Basic language implement OOP constructs, traditional VB developers generally do not use them.

Design patterns should have been an advancement in OOP development. In practical use, however, programmers often use patterns without practicing OOP themselves. Much the same way that procedural developers use Java or .Net and still fail to implement OOP.

The problem for me, as a manager and leader of engineering teams, is finding people who write code that is easy to maintain. To a degree, I equate maintainability with re-usability because code that is reused is not rewritten. And code that is reused is tested frequently. Coders that do not understand or practice disciplined OOP will fall into the copy-and-paste trap. When this happens, many versions of similar code appear throughout the source code, creating a maintenance nightmare.

The irony here is that descriptions of object oriented programming are very common. Wikipedia, for instance has an entry for OOP that a developer could review and understand in a couple of minutes. I hope too, that Computer Science programs strive to instill these basic concepts to their students. In the meantime I continue my search for solid OOP engineers who will help evolve our products.

Recruiting headaches; how not to get hired

I spend much of my time recruiting people for my technology teams. Currently we have openings for software engineers, QA Analysts, and a DBA. Thankfully I have corporate resources to post ads and review resumes. After candidates successfully navigate through HR, I do a short phone screen to gauge the candidate's ability to carry a conversation, and to match their knowledge with their experience (as it appears on paper).

I believe the best developers and testers have a strong academic knowledge of their profession. From this knowledge, good coding habits or solid testing methodology is learned. So my phone conversations always start with a discussion of fundamentals.

For software engineers, the conversation begins with a discussion of object oriented programming. Because I often catch candidate by surprise with this line of questioning, I always list the specific terms we will discuss. Abstraction, Encapsulation, Inheritance, and Polymorphism. I have been applying these concepts for nearly twenty years and expect every competent developer understands how they work in real world applications.

Of course some candidates can not describe OOP concepts. I usually give a lot of latitude on abstraction and encapsulation. These tend to be more conceptual than inheritance and polymorphism, which are implemented with specific language constructs. Imagine my surprise, though, when a candidate recently told me he did not know any of the terms.

When a candidate struggles with my OOP discussion, I try to give him some relief by asking him to define inheritance. Inheritance, after all, is fundamental to all modern programming and is easy to describe; simply define the word. But I was shocked when the candidate admitted that he did not know of inheritance.

This story should end right here, for at this point I politely ended my line of questioning and suggested that we did not have an appropriate "fit". The candidate, however, wasn't quite finished. He assured me that given proper requirements he could finish any project. Then he claimed that academic concepts weren't that important and if necessary he could easily look up the information he needed.

Of course he was wrong. A developer can not possibly build a class library or reusable object without understanding inheritance. In fact you can not write a meaningful Java, c++, or .Net application without inheriting an object. And you can not possibly know when to use an interface without understanding polymorphism. You can not implement objects without understanding encapsulation, and your objects will be a mess if you do not apply abstraction. Most of all, you can not hope to get hired into a position if downplay knowledge an interviewer deems important.
My quality assurance conversions cover testing methods in a similar manner as the OOP concepts. For QA, I have twelve types of tests that I expect a candidate to discuss. In the course of the discussion, I ask that the candidate describe how he applied each type of test in his experience.

I am guilty of acquiring my definitions of the tests from the web. I can't even remember where they came from, but we have a list of a few dozen QA terms. From this list I have flagged twelve to drill candidates. I always start by asking the candidate to describe Black Box Testing.

It was surprising when a recent candidate quoted the exact phrase "not based on any knowledge of internal design or code." Surprising because that phrase is an exact match of the definition on my sheet. I assumed this was a coincidence and continued.

But the next item was quoted exactly too. And the third, Unit Test was again quoted exactly, using the phrase "the most 'micro' scale of testing." Nobody talks like that. She could have at least used the word "smallest".

At this point I stopped her and asked what she was reading from. She denied reading the responses. I mentioned that I was reading my terms from a sheet that we had acquired long ago, and asked where she had gotten her material. I do not believe it is possible for anyone to have memorized those specific terms using such precise language. Again, she denied using reference material.

Generally speaking, I would not fault a person for using notes or reference material during a phone screen. But I expect they can show how an academic concept makes sense in real situations. I would also expect a person to acknowledge using reference material when it has become obvious to the interviewer. She had the opportunity to look resourceful, but instead looked like a cheat.

In both these cases, the candidate's resume looked great but they weren't a good fit for our team. These candidates simply didn't apply common sense to our conversation. Want to know how not to get hired? Simple, be unprepared, lie, or ridicule the interviewer's questions; it's guaranteed to keep you out of the position.

The end of an era, say goodbye to an icon

I was shocked last week when I received my copy of InfoWorld. Printed in the corner of the cover was the announcement: "The Final Print Issue."

I have been reading InfoWorld for nearly twenty years. I remember when it was printed on large newsprint. In the early days, the paper was the premier source of information on technology. The articles, reviews, and news were relevant to the industry. I loved Robert X. Cringley when he provided insider information wrapped in his unique humor about Pammy and his Studebaker Hawk.

But the years have not been kind of the paper. The content simply has not retained the same quality and relavence it had during the 90s. Even Cringley digressed into useless gossip from readers and ranting against Microsoft. From my perspective, only Tom Yager remained insightful.

InfoWorld spins the change as evolution; a move away from the print world and strictly into the online world. I see it as evolution toward death. The move ignores the fact that people read newspapers and magazines for the convenience of the media. It's very easy to skim through a paper, absorb the headlines, and drill into interesting articles. No one will skim online content in the same manner.

Everyone knows the web is a tremendous source of information. And every provider of news, technology or otherwise, must have a web presence. The online experience, however, is very different from the offline experience. InfoWorld, for example, was delivered to me. It's the perfect push technology because once it is in my hands I always flip through it. InfoWorld also sends me email with links to their site. These are very easy to ignore, unsubscribe, or filter as junk. I generally ignore them.

I don't see InfoWorld reinventing themselves into Digg. It is still old school and its' web site doesn't put them on the Web 2.0 radar (which is getting tired anyway). In fact, their web-site feels more like CNN than Digg. As for me, it looks like I will be getting my technology news from eWeek and Wired.

Hey Spencer F. Katt, I miss Pammy and the Studebaker.

64-bit OS kicks butt!

Last month I wrote mention that our applications are facing challenges regarding scalability (see Strategies for Performance). One of the strategies mentioned was moving to a 64-bit operating system, Windows Server 2003 X64. Our observations are anecdotal, but the OS kicks ass...at least when compared to the 32 bit Windows Server 2003. Reports that were running for nearly 30 minutes are completing in less than two (minutes).

We recently rebuilt the server for a key customer onto X64. In moving them to the new OS, we made other improvements too. We upgraded their database to SQL Server 2005. We also realigned the storage, separating data and logs onto different physical drives. And changing those drives from RAID 5 to RAID 1.

All these changes will contribute to the performance improvement. We have restructured systems before, separating data from logs and changing RAID, but have only seen an incremental improvement in performance. It's a reasonable conclusion that the greatest improvement comes from x64.

Searching for Code

Have you tried Krugle yet? Krugle is a search engine of open source code and technology pages. It is an indepensible tool to any developer. Need a special snippet of code for a specific task? Type in your search keywords and review the results.

Krugle searches code, tech pages, and projects. Code and projects return essentially the same thing; links to source code. Tech pages will find your search term in blogs and newsgroups.

I find the code search especially helpful. I have searched for grid computing, sorting, and EBCDIC; and have found useful code in each case. For me, the projects are most interesting, as I want a complete solution.

The site has a sweet Web 2.0 interface that includes plenty of Ajax. It also has allows sharing of notes. One point of contention though, I tagged several files with comments, but was unable to find them (my comments) later.

Google also has a code search capability too, but I believe it is inferior. In Google's case, the search results will highlight key words in source code files. True to Google form, its' code search is very spartan. Google does not have the Web 2.0 capabilities of Krugle, but it is fine for quick and dirty searches for very specific algorithm.

Kudos to Krugle. I suggest you add it to your bag of tricks.

Have you tried SearchMash?

Have you tried SearchMash? I like it so much that I made it my default search engine. The SearchMash features page explains how it is unique.

I like that I do not need to click in the textbox to type a new search. It's a little bit of Ajax magic, but it makes a big difference. In addition to a list of web sites, SearchMash also provides separate lists for blogs, images, and video. And you can watch video by clicking the thumbnail.

The searches are provided by Google, so you should have complete confidence in the results.

Need to do a little shopping?

Ok. This has absolutely nothing to do with business or software. But everyone needs to do a little shopping every now and then. Sure Valentines Day is behind us, but birthdays, anniversaries, and special occasions lurk just around the corner.

If you are like me, the "big" gifts aren't a problem. The kids, for instance, make it apparent what they want for Christmas and birthdays. My problem is the smaller gifts; items for co-workers or friends; stuff for my sister on mother's day; etc.

Anyway, here's two ideas. Kali Gift Bag and TranquiliTea. Kali has an eclectic inventory of odds and ends as reasonable prices that are perfect for little surprise gifts. You wouldn't shop for your wife at Kali, but it will be great on Secrataries Day. TranquiliTea is specifically for the tea drinker. Their inventory is unique.

Kali's is geared toward the online shopper. Their web site is pretty typical for a retailer. It's not fancy, but is easy to navigate and has pictures of the gifts. TranquiliTea is aimed at the in store experience. If suburban Detroit is not convenient then you should pick up the phone. Their service is extremely helpful and friendly.

Ok, one more confession; I don't buy a gift for my sister on Mother's Day...I wonder if Kali's Gift Bag will wrap something up for her.

Almost Famous

Ever type your name on the Google page to see what comes up? I searched on mine today and found I am high on the list. When searching for "William McCann" I come up first on Google and Yahoo!, and third on Live (as of 2/28/2007).

When I search for "Bill McCann" I come up third on Google. Yahoo! does not find this site under "Bill McCann", but lists my LinkedIn profile second. I didn't see myself when searching Live with my nickname.

The irony here is that I have taken no steps to assure that I am found by search engines. It must be getting easier to get noticed; no need to take special steps (Doing something right). Or maybe I'm almost famous ;).

Leadership and Self-Deception

I received the book Leadership and Self-Deception as a gift from a close friend of mine recently. The book is written as a parable much like another leadership book, The Goal given to me as a gift (but not from a friend). I have to admit, I do not like the parable format. The stories told in this way seem contrived; no wait, they don't seem contrived, they are contrived.

The book also has no author. Well, OK, no single author. Instead, credit for the book is given to the Arbinger Institute. There is no research behind the story, and no academic references other than to an obscure doctor Ignaz Semmelweis. The book felt like a white paper for a leadership consulting firm. Maybe that is Arbinger's intent, or maybe that's my self-betrayal.

That's not to say that there aren't helpful tips in the book. Like all material of this ilk, there is plenty we can apply to ourselves. In Leadership, the authors make the case that spend our time in boxes, where we rationalize our behavior and blame others. Coming out of these boxes must be like a self-actualizing experience.

I wouldn't be honest if I recommended the book. Certainly the lessons, taken with a grain of salt, could be very helpful. Myself, I will take away some of the concepts and I will be more conscious of delusions. In the end, maybe it will make me a better leader and person after all.

What is a CTO?

Recently someone asked me "What is a CTO?" I answered with nonsense about software engineering and network infrastructure. Thinking back on the conversation I realized how badly I described the role. What's more surprising is that I've held the role, albeit under different titles, at three firms.

First and foremost, the Chief Technology Officer is the technical visionary for the company. In this role he must be the evangelist for technology; keeping products and services competitive. He must set a clear path to achieve the goals for the vision. And he must assure that everyone knows the vision.

A great CTO will be a passionate advocate for best practices of engineering, quality assurance, and technology operations. Of course, to advocate best practices, he has to know the best practices. These practices will include agile development methods, test driven engineering, and thorough securing of infrastructure.

The CTO have intimate knowledge of the technologies required of his vision. He must be passionate about the platform, when the platform is specific; and agnostic of the platform, when the vision is independent of it. The best CTOs are not concerned about Microsoft vs Linux or Java vs .Net. Instead he pushes the platform needed to accomplish the goals for the company.

The best CTO are excellent managers and leaders. They recruit talented staff and have great retention rates. He understands the value of knowledge capital and continuously encourages learning. And he keeps his own knowledge sharp too.

Through vision and planning the CTO will instill confidence from other senior managers. He will keep his products and services best-in-breed. And he will give customers confidence that their solution will get better and better.

These are the points I should have made when asked..."What is a CTO"?

Implementing Agile Development

Sometime late last year I was introduced to the concept of Agile Development. Actually, I had been formulating iterative techniques over the past 10 years. Craig Larman's book simply reinforced my thinking. That is, software is best developed in manageable increments.

The bigger problem is moving a team steeped in serial waterfall methods to interative methods. Some people simply don't get it; they don't get collaboration; they don't get accepting change; and they don't get emphasizing software over documentation. All of which is surprising because most development teams never receive adequate documentation, constantly deal with change, and usually brain storm to solve problems.

For us de-emphasizing documentation shouldn't be so bad, after all, we don't receive good requirements anyway. But strangely enough, there are developers who still believe that one big master documents is necessary for successful projects. These people are wrong. It is wasteful and expensive to attempt to write a complete specification prior to engineering the software.

I saw this first hand a DoubleClick, Inc several years back. The firm hired a team (larger than my current department) dedicated to writing specs. The documents produced by this group were huge, numbering hundreds of pages. And the details were debated ad-nausium, leading to stagnation. What was produced was documents, what wasn't produced was working software.

A greater problem for us is managing multiple projects. Our technologies are not constructed on a common code base. Therefore each project becomes its' own set of increments. Currently we have five projects under development. That's a lot of work for a staff of seven plus four consultants. With all these concurrent projects, managing increments becomes difficult. Afterall, it isn't practical to deliver an increment every week. Or is it?

We seem to do alright with collaboration, but there is room for improvement. It helped to implement daily stand-up, or scrum, meeting. The meetings are short and focus on the goals for the day. We have not attempted to implement strict pair programming, althought there is very frequent teaming on tasks.

I remain a strong proponent of agile and iterative development. Over the next couple of months we will be able to take an objective look at the results of these methods.

Strategies for Performance

Like many growing technology companies, we frequently wrestle with performance and scalability of our offerings. In our case, we're tied pretty tightly to Microsoft; a hold over from a time when the products were built using Access. We've since moved on to Visual Basic, c#, .Net, and SQL Server, but we are not platform agnostic.

We're also taking steps to move off a pure client-server architecture, and to an n-tier architecture delivered through a browser. Typically our applications have a small number of users who submit long running queries. There are two primary stress points for performance, loading the data repository, and running queries (reports).

We are attacking the problem across several fronts. First, we're throwing hardware at it. Second, we are upgrading the OS and database platform. And finally, we are optimizing the applications. Note that we are not considering using a server farm for the application servers. We believe the low number of hits to the web apps make scaling the application server a lower priority.

Throwing hardware at the problem is the easiest and quickest way to scale. In our case, that means moving the application server to a separate box, and purchasing more power. More memory, more speed, and more processors. We all know, however, that this type of solution simply covers up bottlenecks in the application.

We are also stepping up to SQL Server 2005. In the standard edition, which most of our customers deploy, SQL Server 2005 will use 4 CPUs and as much memory as the OS can give it. Some of our customers are CPU and memory bound when using SQL Server 2000. Stepping up to 2005 is a significant boost. SQL Server 2005 also runs on Windows 2003 64 bit.

The 64 bit OS appears, in our sample testing, to give a huge performance boost. Unfortunately, it also gives us problems with some of our applications. Most significantly, we have not successfully deployed .Net 1.1 on the OS. Therefore, all our web applications must be migrated to Visual Studio 2005. We found that moving our web applications from VS 2003 to VS 2005 required some work. We are still trying to work through problems with deployment projects for these applications. Our Visual Basic legacy clients flat out do not run in the Terminal Services environment.

Finally, we are confronting the code in the applications themselves. The products have evolved from a client-server architecture. The software requires an active user that performs key functions synchronously. We will move file operations and reporting to asynchronous classes. This frees up the UI and gives the user a responsive experience. But asynchronous does not make queries run faster. Improving query performance requires reviews of the execution plan, indexes, and index views.

It is tedious work, but it will payoff in greater revenue.

New Year Resolution

January 2007. A new year; a fresh start. OK, not exactly a fresh start. There is plenty of carry-over stress from 2006. But a lot is new too. My first, recently acquired, has a bright a new future as part of a much bigger family. We are also taking a fresh look a engineering software...adapting to the "Web 2.0" (now there's tired phrase) and adopting iterative development practices.

We had spent much of 2006 recruiting talent, reducing dependence on consulting, and introducing an aggressive slate of products. Now the challenge is tying our offering into a cohesive suite of applications that are scalable and easy to deploy. This includes our push to migrate legacy software written in Visual Basic (yes VB 6.0 client/server) to a current infrastructure. This challenge is as much political as technical.

So the resolution? It's sharing the experience, the same resolution made (and not kept) a year ago. This year my goal is to share both positive and negative experiences, thoughts, and ideas. Topics will include recruiting talent, migrating legacy code, engineering methods, and things I just don't foresee. And I'll try to leave my personal goals (fighting my waistline, renovating my home) out...usually.

In any case, here's to yet another new year and another resolution to keep or break (time will tell).

Open Source Software

As a builder and seller of software, you may think I would not be a proponent of Open Source. And you would be wrong. I love Open Source; not for idealogical reasons, but because I can get great applications at little or no cost. Our firm is fairly small, and it's important that my modest development staff remain focused on engineering products. For internal requirements, we often turn to Open Source.

One such application is the Blogging software blojsom. And no, this blog is not written with blojsom, I use regular ole Blogger here. Blojsom was easy to set up and meets our needs for corporate blogging; which is actually a journal style knowledge base. Blojsom isn't perfect, administering a blog is clumsy, as is adding and editing entries. But the application is stable and attractive.

We also use Moodle. Moodle is software for running web based education. It is very mature and feature rich. We have only scratched the surface of the application's capabilities, but I am impressed. Moodle has the advantage of an active community.

Of course underneath these applications is Open Source infrastructure. In our case this includes MySQL, Apache Tomcat, and PHP. I don't believe any of these are up to the task of their commercial counterparts, but for the internal needs of a small business they are perfectly fine. With the exception of PHP, these were very easy to set up on a Windows 2003 Server. PHP was a bit more difficult as we configured it with Microsoft IIS instead of the recommended Apache web server.

Although not open source, we also use the free application Actitime from Actimind. Actitime performs timetracking. Interestingly, it uses a combination of ASP.NET and MySQL. I highly recommend Actitime and have considered using their developers as consultants on some of our development projects.

These are real apps being used by a real company to do business on a daily basis. Our usage of these applications clearly demonstrates the traction made by open source providers. I look forward to expanding our list; anyone know a good open source accounting package? Or how about CRM? ERP?