Is it October yet?

Although, here in Kansas City, it still feels like October (kinda chilly), we are many months away. Still, I am anxiously awaiting for October 2008 to arrive because that is when the Southwest Fox 2008 Conference will take place. Last year's Southwest Fox 2007 Conference (featuring EVERYTHING you ever wanted to know about Microsoft Visual FoxPro) was the most attended ever; bucking the trend of reduced attendence at VFP conferences. There is no reason why this year's conference can't be even better. It was HIGHLY received by the attendees last year, and first time organizers, Tamar Granor, Rick Schummer, and Doug Hennig are in the process of building upon last year's success.

There are several ways in which the conference can be improved and one of them is to spread the word throughout the FoxPro community about the conference. It is in that spirit that I am pointing you to one of the pages on the ( Southwest Fox website ) that is specifically designed to assist community members in publicizing the conference, the ( "Promote the Conference" ) page. On that page, you will find several ways to help promote the conference and spread the VFP "Word".

I am particularly directing your eyeballs to the section displaying two animated banner ads. One (or both) of these banner ads will easily fit onto a page of anyone's website and/or blog. You can cut and paste the HTML code provided to easily display the banners. It would be a genuinely unselfish gesture if each and everyone of you reading this blog would take the time to post an ad (as well as pass along the URL to the promotion page to others likely to post an ad). Incidentally, if you don't, it will reflect on your parents and a big, black checkmark will go on your permanent record. Seriously, anyone who loves Fox and wants to see it continue to flourish is encouraged to post an ad banner. Your help in making the 2008 conference the best one yet will be greatly appreciated.

Lastly, if you are interested, the call has gone out to all those interested in being a speaker at the 2008 conference.  Details are on the Southwest Fox website.

Sometimes, It Is the Small Things In Life That Count

Has this ever happened to you?  It happens to me a minimum of once a week, but NOT ANY MORE!  Most often it happens when I am copying a directory (yes, I am “old school” and refuse to say “folder”) full of files from a hard drive to a thumb drive. I know that the process will take a few minutes so I begin the copying and go get a drink refill.  Adding fresh ice, topping off the glass, and meandering back to the computer, I notice a message on the screen.  Have you seen one similar to this before?!?!

                    

While not completely wasted, the time getting my refill wasn’t as productive as I thought it would be because the copying process did not complete, but, instead, paused waiting for my input. I said “Yes”, but then had to wait for the process to complete. What a pain. Oooh, thank you Microsoft. I certainly wouldn’t want to overwrite a file that I can recreate any time I want to (usually whether or not I actually want to). The fact that it is referred to as a “system file” makes it seem that much more important, too. Well, in MY opinion, (I use the phrase, “in MY opinion” so that if I am wrong in anything I say, I can just say that “MY opinion” was based on MY experience) there is very little upside by even having these Thumbs.db files hanging around all over the place.  If there was only a way to prevent them from propagating like tribbles in heat.  Hey, there is!

I ASSume that the main purpose for these files is to have a way to easily (and quickly) see thumbnail images of any graphics files.  Nice concept, no problem. It does take some amount of overhead to create the file, but to me, the time is insignificant unless you had a couple thousand .jpgs in a directory (and then, I would question THAT behavior). At any rate, you can prevent the OS from automatically creating (AND THUS, ELIMINATING THIS ANNOYING “FEATURE”) as follows:

Open up Windows Explorer, go to the menu Tools|Folder Options| click on the “View” tab, and under the “Files and Folders” section, look for the checkbox with the caption, “Do Not Cache Thumbnails”. Stick a big, old, fat check in that box and from now on the Thumbs.db file will not be written to your hard drive. Yes, you WILL still be able to select Thumbnails as a format to view the directory’s files, but since it is not written to disk, it is never copied, and you will never see the above message again. As I mentioned, there is a very minor, minor, minor performance hit each time you request a thumbnail view, but it is a small price to pay (again) in MY opinion. Ah, life is good.  Sometimes it’s the small things in life that count.

When to Consider Custom Software over COTS?

When your business requires a software solution, you have two directions in which you can go — Custom or COTS (Commercial Off-The-Shelf). Which path you choose depends upon considering a number of factors. It is our goal to arm you with information that will enable you to make the best business decision.

For this article, we will define “custom” software as computer software that the business owner has contracted to have written for their company. Traditionally, custom software is written by a third party entity; usually an outside software development company or a team of in-house personnel. COTS software is usually purchased from a retailer or from a vendor who has developed the software and mass-markets their product to many businesses (usually within a vertical market).

It’s not always easy to decide between custom or COTS software since it often requires long hours of deliberation and an understanding of the pros and cons of each choice. In the spirit of full disclosure, the authors’ main source of income is derived from creating custom business software; however, since we realize that there are times when custom software is not the best solution, we will attempt to present a balanced description of the pros and cons. Reviewing the following pros and cons will make that daunting task easier.

Custom Software – PROs:
Gives you exactly what you need – Each business has its own set of unique business rules. Often, the only way they can be computerized is via custom software. Why pay for features that will never be used?

You own the source code – Owning the source code affords you more control over future enhancements. When clients see the value of custom software, they become more sophisticated and quickly find specific ways to improve their particular business work flow. When ideas pop into your entrepreneurial brain, you can have the existing software modified to incorporate those ideas. Additionally, owning the custom source code is a valuable asset; an asset that should be included in the price of the business if it is ever sold.

More useful reports – There is no reason to have software unless it can produce the desired output; this is often in the form of reports. Custom software allows for the creation of meaningful reports that are used to make astute business decisions. You, the business owner, can ensure that reports give you the information the way you want it; not how the vendor thinks you want it.

More efficient in-house help desk – Help desk personnel will be more familiar with the business rules involved and can assist users. They will know about common issues, traps, and work-arounds. This is much better than having to explain a specific issue to COTS help desk personnel who usually deal with generic problems.

Decision makers are readily available – During the design phase, decision makers are available to make judgment calls. They have an intimate knowledge regarding how the software should work. Users are very good at describing the work flow and as a result, the software can be more effectively designed to increase their efficiency.

Vested users readily accept the software – If the users have had input into the design of the new software, they more readily accept the changes. Plus, they are ahead of the learning curve because they’ve been exposed to the software during the development stage.

Money is not wasted on unnecessary features – A side benefit of getting the exact functionality you want in the software is wisely spending your development dollars. Every dollar that is spent goes toward making the best possible product.

No major license fees – You own the code. You own the software. You control its use. This is not to say that annual fees, hardware enhancements, and other “cost of doing business” expenses don’t exist. Most likely, they will exist, but you will need to find out what they cover, how much they are, and compare them to the same fees for the COTS software.

Custom Software – CONs:
May cost more – It is custom software and one would expect to pay more because custom “anything” is labor-intensive. Depending on the scope of the software’s capabilities, it could be considerably more expensive than “canned” software; only you can decide if the derived benefits are worth the expenditure.

Not immediately available - Depending on the number of developers, the scope of the project and other factors, it may take months for the application to be created. This may be greatly reduced by using developers who employ proven software development practices such as a framework, agile processes, test-driven development, etc.

You may be re-inventing the wheel – Most applications have many of the same features as requirements; printing reports, displaying data, and adding or modifying data are such examples. Time, money, and effort will have to be spent with respect to these basic tasks.
 
COTS Software – PROs:
Immediately available – Upon purchase, the software is yours. Deploying the software and establishing the user environment is up to you; as is getting it to do exactly what you want.

May cost less – The initial cost will almost certainly be less than any custom software. You may have a licensing obligation, though, where you must pay a fee on a per-user basis.

Don’t have to re-invent the wheel – For performing basic data functions, COTS software should be able to do the job. Basic customer, sales, basic reporting, and invoicing tasks could be handled as long as you are willing to do it the way the vendor wants you to do it.

Technical support – Technical support is sometimes free; sometimes, it’s pay-by-incident. Hopefully, the COTS personnel know their package and can relate to your specific issues.

COTS Software – CONs:
Little extensibility – The software may or may not be able to implement the features you desire. However, some COTS packages allow for some extensibility via a user scripting tool or via a report writer that enables the user to develop their own custom reports.

Usually “work-arounds” are required – There may also be additional expenses to implement required “work-arounds” to handle specific needs for your particular business; even then, you might not get the result you desire.

At the mercy of the manufacturer – You have no control as to when updates, bug fixes and new features will be available or even if they will ever be available. Vendors typically respond to the concerns of “squeaky wheels”. If you are the only one experiencing a specific issue, it could be a long time before it is addressed, if ever.

Non-Vested users can become frustrated – Users have no vested interest in “canned” software and there is a psychological component when installing new software. Users are placed on the “learning curve” and it usually isn’t fun for them; people are reluctant to change.

Potentially major license fees – Some vendors charge annual license and/or subscription renewal fees.

In summary, if you find a COTS package that meets your requirements and is reasonably priced, then go with it. However, if you need a solution that more closely meets your business requirements, implements rules for your specific business (not just for the vertical market in which your business resides), and is flexible enough to change as your business changes, then you would be doing your business a disservice by not considering a custom software solution.

- Art Bergquist and Dave Aring

Jim, I hate you.

I was working on site for a client recently when I said, “Jim, I hate you.”

Jim’s head pops over the side of the cubicle next to me. He flashes me a quizzical look and asks, “Why is it that?

“Because, I can’t write a single line of code now without writing a test to support it. It is all your fault.”

He smiles and replies, “Well, if you are blaming me for writing better code, I’m ok with that.”

Just in case you don’t know, Jim Erwin is our resident rock star (literally, he was a musician in a previous life) and the author of FoxUnit, a unit testing framework for Visual FoxPro. He is also the Software Development Practice Manager and the evangelist for Test Driven Development (TDD) at Visionpace. In addition to having a great sense of humor he is my ever patient coach on TDD.

I took my first TDD course from Jim and I have been incorporating it into my development practices ever since, but not without some trepidation. I try to keep myself open to new methods and try not to discard a new idea until I have tried it. I will usually adapt a new idea into my development and practice it for a while before I make up my mind on how useful it is. My first impression of TDD was that it really wasn’t that different from how we always did things. Other than that whole idea of writing a test that was bound to fail before you even start, how different could it be? We always test our code, right? I mean, it is not like we write some code and just throw it out there for our users. So how is that TDD thing so different?

It wasn’t until I developed the habit of testing my software with unit tests that I really found that out. I have to admit that it wasn’t easy at first. There were all kinds of problems. Most of which I created by not following good practices. Early on I wanted to test everything with FoxUnit. I tested forms and reports and anything that was part of my application. But that is not what unit testing is all about.

As I progressed as a student of TDD, I began to realize that unit testing meant just that. You test units, not complete applications. As developers we are familiar with the concept of writing small pieces of code with discrete functionality. I realize that I’ve known that for years. It was something that I was taught in college, and that was longer ago than I want to admit. However, it wasn’t until I started unit testing that I really became aware of what that meant. I thought I knew and practiced that.

The more I tried to test my software the more I started thinking of how I could break it down into testable units. There were times I wanted to test some object but I would end up testing ten other things at the same time because of the built-in dependencies.  That forced me to look at how I could reduce those dependencies.

As I continued to practice TDD I found myself thinking of how I was going to test the software before I wrote it. When I realized that, I also realized that I wasn’t really doing TDD. When you practice TDD, you write the test first and the code later. What I had been doing was writing the code first and trying to find a way to test it later. When I started writing the test first, I started finding ways to reduce the dependencies. 

Jim, I hate you because I can never write code the same again. You taught me to use TDD. You opened my eyes to a different way to write software. You forced me to see some of the imperfections in how I write code. My code is cleaner because of you, and I have the tests to prove it.

Jim is smiling, and he is ok with that.

…

If you are using FoxUnit or practicing TDD, I would love to hear about your experience. Send us an email or stop by FoxUnit.Org and let us know what your experience has been.

All Those Who Liked Doing Book Reports in School, Raise Your Hand

I hated doing book reports in school. I usually tried to “read” a book that had been made into a movie. I preferred to “watch” a book rather than read one. I gave up this approach when I once reported on Jules Verne’s “Around the World in Eighty Days”. Turns out the much bally-hooed scene of Phineas Fogg going over the Alps in a hot air balloon was never a part of the actual novel; it was just a Hollywood gimmick and my English teacher was aware of that fact. Anyway, why would I want to read a book when I could be outside playing? I haven’t changed too much over the years. Why would I want to read a book when I could be inside playing (on the computer)? I rarely read for pleasure, but I almost always have a technical book, white paper, or trade magazine with me. You just have to “grow ‘til ya go”.

The latest book I have been schlepping around is “Flying Fox – Applying Visual FoxPro Reporting to Any Data, in Any Environment” by Lisa Slater Nicholls. “Flying Fox” is an easily portable paperback (about 140 pages) offered by dFPUG (Deutschland FoxPro User Group). In Europe, it may be ordered at http://tinyurl.com/2pa32x. Here in the colonies, Whil Hentzen’s Hentzenwerke Publishing is handling the domestic distribution and can be ordered at http://tinyurl.com/2naej6.

What this book lacks in physical presence, (it is just an average sized paperback), it more than makes up for with content and the urge to think “outside the box” with respect to creating application reports. The introduction sums it up quite nicely. “Database developers who have never used Visual FoxPro can use this book to learn how to use VFP as a low-cost and full-featured reporting tool for their data sources. Even if you don’t use VFP for anything else, VFP makes reporting accessible, extensible and cost-effective.” What business owner would not be impressed by that degree of flexibility and cost? Not many. I want to re-emphasize that this book and its concepts are not for Visual FoxPro users only. One word of caution… If you are using a version of FoxPro that is earlier than VFP 9.0, you will have to upgrade to take advantage of all of the concepts; specifically, the use of the report listener classes. Another important point is that even though Nicholls states that you don’t need to know VFP, you will have to learn some FoxPro. However, this should not be a showstopper since she takes several chapters to draw you into the VFP environment as well as explain the commands needed to accomplish your goals.

Additionally, more chapters are devoted in the step by step development of a VFP reporting application. In summation your honor… I would like to state that I have read through the book twice and although I consider myself to be somewhat savvy report-wise, I still do not fully understand all of the concepts. It is not because of Nicholls’ explanation, but rather, reluctance on my part, to get my hands dirty since I do not have an immediate need for this functionality. I am confident that once I actually place my fingers on the keyboard and start to build my reporting application it should all come together. For me, it is simply a case of adding another tool to my development arsenal and I am suggesting that you consider making yourself aware of these reporting possibilities also. Read the book, now! It will be years before Hollywood makes it into a movie.

Porters! Presort!

Most of the applications I write are data-centric. People put data IN, the application manipulates the data in some way, and people take data out. Nine times out of ten, the data is taken out by putting it into some readable format.  I like to call that readable format a report; oh, wait, so do 100,000 other developers. Nothing new there, but the 100k number is greatly reduced when those developers are asked if they actually like to CREATE a report.

For the most part, creating reports is not glamorous. Creating reports (much of the time) is not very challenging. Let’s face it, creating reports is quite boring. However, just as I would like you to look at the title of this blog in a different way, looking at reports from a different perspective may allow you to gain respect for this much, maligned aspect of application development. So, looking at the title from a different perspective… you might see… Reports!  Reports!

Many senior developers just pass off the task of creating the reports to the junior developers.  If that is your M.O., so be it. At the very least, I am suggesting that you take on the additional responsibility to review all of the reports that are produced from within your various applications. Here are a few reasons why.

1. Quite often the person who ends up reading the report is the same person that approves the check that is given to you for your services. i.e Middle to upper management. The “grunts” enter the data, the application processes it, and the data flows uphill to management. It is often the case that management bases the success of the application development process on the physical output – namely the reports they read.

2. If those reports are clear and concise this is a good thing. If they are easy to read and understand, this is even better. Even nicer is the fact that columns line up, fonts match, data is accurate. In other words, it gives the management-type a “warm and fuzzy” feeling in their tum-tums.  That is definitely a good thing.

3. A group of reports that are “standardized” is a factor in making the overall application appear to be professional. Using similar formats for cover sheets, using similar (if not identical) fonts, and standard headers and footers go a long way in allowing the reader to interpret the report. Much like following a standardized menu design that is similar to other menus in Windows-based applications, a standardized set of reporting design features enhances the overall application.

Give the design and format of your reports the same care you give your code and it will pay dividends. Give reports the respect they deserve. You will be glad you did.

Why use Tasks?

As we coach software development teams in Kansas City, we are often asked about the process of breaking User Stories down into development tasks (anything related to implementing and verify a User Story). This is one of the areas teams struggle with when adopting an Agile process. It's actually something they often struggle with using most any process but most Agile approaches rely heavily on it for a number of reasons.

1) Iteration Planning

Tasks are a good last check for iteration planning purposes. Even though we can rely (to some extent) on past  actual velocity to get a sense of what a team might be able to achieve in subsequent iterations, breaking stories down into development tasks/hours allows the team to leverage what they've learned so far during a given release in terms of some stories being potentially larger or smaller than previously thought. They can use that information to develop a better, more reliable/realistic iteration plan.

During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the stories selected for the iteration. During that discussion they can help each other clarify and improve their development plan and discuss lesser known areas of the code, database, etc. to help other team members learn and become more productive in their development.

2) Iteration Burndown (what's left <how many hours> to do within a given iteration)

Having tasks with hours estimates enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a story was initially discussed, why some tasks weren't ultimately needed. With this information, it becomes apparent that at times, developers may be struggling with a given task and may need help.

It also enforces thinking more thoroughly about tasks needed to complete a story and aides in becoming better at tasking and task estimating during subsequent iteration planning meetings. It also allows the team to get an earlier sense of whether the goals and story points planned for a given iteration will be achieved and allows the team to consider adjustments sooner.

3) Accountability

Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating. It can encourage team members to seek assistance on tasks they might be struggling with as their 2-hour task still isn't done after a couple of days effort while the teams velocity begins to become negatively impacted.

Developing for a story without tasks can lead to stories that don't get done or done as hoped. Without tasks, the team loses the ability to provide assistance (since nobody knows what you're doing) and overall iteration and ultimately release predictability suffers.

4) Shared and Individual Learning

Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all stories and helps them to become better definers and estimators of tasks.

5) Tasking Encourages Better Design

Thinking through a plan of attack for implementing user stories and creating steps (a.k.a tasks) to achieve it tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete story implemenation.

6) Forecasting Velocity

When you don't have the luxury of running an iteration to get an actual velocity but need to provide stakeholders with some sense of cost and schedule, you need to forecast the teams velocity. Using tasks is very effective for this. Do this by estimating team capacity, breaking stories down into tasks/hours until the capacity is filled and adding up the points for the stories you just tasked. You now have a forecasted velocity to provide a preliminary forecast of cost and schedule.

7) Tasks Serve as Reminders

When you task, typically at the beginning of an iteration (during the planning meeting), you have the users  attention and are able to ask questions to which you'll need answers to enable you to think about your plan of attack for a given story in terms of development tasks that will be necessary. Even a few days into the actual iteration, you'll forget at least part of what you discussed with the user if you don't have recorded tasks and you'll have potentially less access to the user to confirm/reconfirm tasks and/or stories.

8) Talk to the Dog

Having to talk out loud and/or in a public setting about tasks you'd need to complete a user story tends to create greater focus than just beginning to code. It typically creates better overall productivity and thoughtfulness in approaching the implementation of a story.

9) What if you hear, "I can't/won't task."?

If a team or team member simply says they won't task, that's more of a personal discussion. Obviously asking them why they won't task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.

When a team or team member claims they can't task you have more information to work with. A common stated reason is that they "just have to start coding" and don't really know about the tasks until they start working on it. One approach is to say "Fine, then write down the tasks as you uncover them during coding and we'll discuss and learn from those to make you a better up-front tasker.". You can also allow a "research" task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.

Above are just a few broad reasons why tasking is useful for software development, in particular for Agile processes.

Liar, liar, pants on fire!

Before I start this diatribe, give me a minute to get up on my soapbox. Ah, that’s better. The air up here is not as polluted and I can see more clearly now. Too bad some of you can’t get up on the soapbox with me to enjoy the view, but I digress. OK, before going any further, I warn you that I am about to offend a lot of “kool-aid drinkers”.  If you are one of them, tough toenails, because I’ll give you the bottom line right now – you, my friend, are an idiot.  If you don’t have thick skin, read no further. Those of you brave enough to face the truth, continue on.

We here at Visionpace make every attempt to practice the Agile methodology of software development. We are proud of the fact that this practice serves both us, as software developers, and our clients extremely well. Many of our clients were reluctant at first, but once they understood the benefits, most of them gave it a chance and haven’t looked back.

Agile practices are a good thing, but I do have one beef that I am VERY passionate about and I am about to discuss (some of you might even say, proselytize) it. In many agile discussions, as well as discussions about other software disciplines, one often hears the phrase, “All comments are lies.” Those of you who believe this are (as I have alluded to above) idiots! However, those of you who do NOT believe it, COULD still be an idiot, and so, be sure to get a second opinion.

Hey, I get it. Don’t trust comments. They are not always accurate. Duh! I feel that there are a certain percentage of you out there who actually embrace this belief because it validates the fact that you were doing the right thing all those years by NOT putting comments in your code. No, it just validates that you are lazy. Lazy is not, necessarily, a bad trait in a software developer, but NOT commenting your code WITHIN the code makes you, dare I say it, an idiot. That is the last time I will use that term, because, hopefully by now, you are riled up enough to really listen to me.

Other than the fact that someone either knowingly wrote an inaccurate comment or wrote a comment, modified the code pertaining to it, and then did not update the comment, can any one out there give me a reason NOT to trust a comment you discover in code? We will exclude that person from the discussion because he is a “psycho programmer”; you know the one that NEVER follows any kind of standard and use one character mvars. Besides, most “psycho programmers” don’t comment anyway.

Here are the reasons why you SHOULD comment your code.

1. Let’s get the “trust” issue out of the way right now.  If YOU put the comment in yourself, you BETTER believe that the comment is accurate. You did it (primarily) for yourself.  The fact that an accurate comment will benefit a maintenance programmer who comes down the pike a year later is an extra benefit; a benefit which I appreciate when I am called in to do the maintenance. I will be more than happy to ASSume that the newly discovered comment is accurate because THAT developer put it in there and, like you, why would they want to lie to them self? Yes, there is that chance that the comment is now inaccurate.  Studies have shown, statistically, that approximately 93% of comments ARE accurate.  Right here, you should be asking yourself where I got those numbers, and right here, I will tell you that I made them up.  Who would waste their time researching that fact? Nevertheless, think about it, most comments ARE accurate because the person who writes them WANTS them to be accurate.

2. OK, I can tell you are getting a little bit peeved right now. Dave, I thought our code is supposed to be “self-documenting”? If I write bug free code, why do I have to comment? Oh, grasshopper, you will learn someday.  Until then, trust me, write those comments! In all honesty, I, too, am a believer that under most circumstances, the code SHOULD be self documenting. However, consider the following code:
   
   

REPLACE Name WITH UPPER(SUBST (LastName, 1, 2) + LOWER(SUBST (LastName, 3)

That code is self documenting, if someone wanted to take the time to figure out what it does, they could easily do so. The real question the person should be asking their self is... WHY is that code there? It looks kind of goofy anyway.  When I first saw it, I thought that perhaps the coder didn’t know about the PROPER function, but then, they were really capitalizing the first TWO letters of the name. Maybe the parameter of the first substring should have been 1, 1.  Maybe I should refactor using the PROPER function.  I am soooooooo confused!  Close to an hour of my time was spent determining WHY this code was here.  Imagine how much easier it would have been had the following comment been in place.

DLA/Visionpace 04-01-2004 Mr. Jones, the COO, bought 113 file cabinets at an auction. He has decided that the new company wide filing system will be based on the first TWO letters of the customer name. EACH drawer will have a two letter designation and the file will be placed in the drawer base on the first two letters of the customer name. To make it easier to file, he wants the first two letters emphasized for easier reading.

Immediately, we can see that the code is correct and that there is a reason WHY it was written.  Additionally, as often happens to me, in some scrum, when asked why this was done or who requested it, the answer is there.  Not only for me, but for you when you come in to do the maintenance. Two minutes to initially write the comment or 60 minutes to figure out the details three years later. You do the math.

3. Additionally, what one developer feels is self-documenting, another might not. Why not eliminate any potential confusion and explain the reason for the code’s existence? Again, it will save the next person who comes along much valuable time for there is a real good chance that they will know nothing about the project and the code. Believe me, you will benefit also.  One of my favorite phrases is... “When you are coding, you and God know what you are doing.  Six months later, only God knows.” I can not begin to tell you the number of times when I have gone into some legacy code and the comment I wrote three years earlier IMMEDIATELY brings back to life the exact reason for the code.  Many is the time that it has saved my fanny. Those are the times that I almost dislocate my shoulder patting myself on the back for a job well-done.
   
   

If you have made it this far, you are just not getting enough billable hours in.  However, thank you for reading along and agreeing or disagreeing.  Either way, I would appreciate hearing your thoughts on this very polarizing topic. I promise to bring an open mind if you do the same, but I will say right up front, that it will take a Herculean effort to change my mind.  Care to give it a try?

Denial Isn't Just a River in Egypt

A little over a month ago, the Microsoft Corporation officially announced that they will not be releasing any new versions of its relational database software, Visual FoxPro (VFP). The news came as a surprise to many of the developers in the FoxPro community, but those developers must have been in denial or had their heads buried in the Hentzenwerke “Hacker’s Guide” because the handwriting has been on the wall for months.  Years!  Decades?
 

To paraphrase Garrett Morris’ Chico Escuela persona from “Saturday Night Live”, “FoxPro has been bery, bery good to me”. It has provided me with an above average income and a comfortable life style (once I kicked all of my kids out of the house). More importantly, Visual FoxPro and before it, FoxPro for Windows and FoxPro for DOS, has been VERY, VERY good to thousands of small to medium sized business as well as some Fortune 500 companies. A VFP application is used to run the operation of the Chunnel (the underwater link between England and France). During the first Gulf War, FoxPro was an integral part of the military’s JFast application which managed the deployment of troops and supplies. There are many other high profile applications, but my point is that mission critical applications created by FoxPro developers provided reliable, efficient, and economically sound solutions to real world problems. ECONOMY is one of the reasons that Visual FoxPro is one of the best selling application development software tools IN THE WORLD. It is reasonably priced and is “self-contained”. i.e. For the most part, it has it’s own reporting capabilities, user interface capabilities, and data storage capabilities. Those are the basics of most data-centric applications. Of course, it has many, many more features than just those basic capabilities. I could go on about my devotion to VFP and why I (as well as many other developers, world-wide) love it so much.  Nevertheless, the fact is that Microsoft is going to support Visual FoxPro only through 2015, so there is no sense in denying it any longer. VFP is on its own.

Notice and this is very important, I did NOT say that VFP is DEAD.  I just said it is on its own. Why? Because 2015 is eight years away.  Who knows what will happen by then? I, personally, am still maintaining applications written in the mid 1990s that the clients love and couldn’t do without.  I expect to see applications, being written today, around for another twenty years.  The applications do EXACTLY (another key word) what the client wants them to do and they have no plans of abandoning them.  Isn’t that the bottom line? So, if you are in need of custom applications and plan on being in business for the next 20-25 years, there is no compelling reason why you shouldn’t consider (or at the very least, do not summarily dismiss) having those applications written in Visual FoxPro. An honest, ethical developer should offer you all options, explain the pros and cons of each, and then help you to decide upon the approach that is best for you.

Let the Ultimate Metric Build your Team

At a recent Agile KC meeting in Kansas City, Missouri we met to discuss, among other things, topics that might interest software developers and managers alike for upcoming meetings. One of the topics that always comes up when such a list is discussed is testing. It's interesting to see how software developers increasingly are discussing ways to test software. Everyone (QA, developers, managers, customers, etc.) wants to know what "done" means.

I know we have seen increased interest from our consulting clients in Kansas City where we coach software developers on agile software development techniques and teams and managers on agile project management. Software developers are interested in defining "done" (just as other stakeholders in the project)through the use of not only unit tests, where they're able to demonstrate the integrity of the code at the unit level, but also in terms of acceptance testing or functional testing where the focus is on defining "done" in the customer's eyes.

Acceptance tests sometimes known as "conditions of satisfaction" define the requirements for software features which are most often comprised of one or more user stories. They are defined from the perspective of the customer for a given business need, exactly where the emphasis should be in the first place. So the combined set of tests ideally maintained and run in an automated fashion to help speed up development, make up the overall requirements for the system.

Having the requirements defined in advance of each iteration planning session is a highly effective way to keep the team pointed in the right direction and create a focus for software development efforts.  The idea is that at the end of the each iteration, working software is available to potentially ship because it works or is "done" in that it has passed the tests defined at the beginning of the current iteration and all tests defined in previous iterations.

Knowing what targets to shoot for each iteration lets the team focus on what needs to be done, eliminates gaming other metrics in use and helps a team identify what adjustments they need to make to reach the goal of delivering running tested software every iteration in a just-in-time manner.

This emphasis not only ensures the software output matches the requirements but it results in leaner, more concise and targeted code that's developed with those conditions of satisfaction in mind. There's less of a tendency to get off track and build features that weren't requested resulting in overall lower maintenance costs and an overall better team in that they develop a shared understanding of the business domain and the software that supports it. It also helps with schedule and cost predictability in that untested code represents an undefined amount of work (potential bugs) that, if left to deal with toward the end of a project, can create wack-a-mole development that often accompanies the classic "stabilization" phase.

We have found that this "ultimate" metric is the best target to hang out at the end of every iteration. Even if it takes a number of iterations to establish the necessary rhythm to achieve the frequent and consistent delivery of running tested software, it's a goal worth tracking and building a team process around.

Static, Thrashing and other Communication Dysfunctions

I was recently in a planning poker meeting which is a step in the release planning phase for agile software development projects where user stories are sized relative to each other. This is a critical step to estimating the cost and schedule of a project. By the way we typically call these meetings in our process "sizing" rather than estimating because we are specifically sizing the stories relative to one another, followed by another step to actually determine the estimate in terms of hours and therefore cost and schedule. 

This was one of the most painful meetings I've attended in recent memory. Painful because of the communication (or lack of) taking place during the meeting. While there was no shortage of experienced and talented developers and other stakeholders in the meeting there was a significant shortage of meeting etiquette which resulted not only in the typical thrashing that can plague such meetings but in interruptions, sidebar conversations and conversation threads that didn't pertain to the specific user stories or in some cases the project being sized.

We typically track the time it takes on average per user story across projects when it's feasible to do so in order to inspect and adapt and find ways to optimize the time we spend sizing each story.  What we noticed at the end of this particular meeting was that over 80% of the time spent was in the area of discussing items not specific to the story or in some cases far too specific, which was an indication for us that not enough time was spent in the most productive parts of sizing a story.

Based on this performance we have decided to display simple meeting etiquette rules similar to those types of rules we've seen in other corporate meetings reminding people to focus on participants as they are speaking and to try to limit interruptions unless they feel they're absolutely necessary in terms of understanding the point at hand and limiting side conversations, again unless they're seen as necessary. 

In the context of a user story sizing meeting we've also reminded ourselves of simple adjustments such as letting the customer read the story and then letting developers ask questions by taking turns. We'll ask those people not speaking to write down points or comments they feel they need to make. We hope these steps will go a long way towards focusing the conversation and reducing the needless amounts of static that we witnessed during this meeting and in general help optimize the time spent sizing stories across all of our projects.

While we acknowledge the fact that it's impossible to completely eliminate things such as interruptions and thrashing and even some sidebar conversations especially when you have very bright and creative people in the room such as we did for this meeting, we also feel strongly that if this isn't addressed it will result in not spending resources wisely.

Shaking Things Up

We talk a lot about our experiences in this column about our agile software development practice...so much so, that perhaps it sounds a little self-serving at times. After all, we're heavily invested in agile methodology. So here's a link to another developer's (Russ Nemhauser's) blog...a developer who joined an agile team at a Large Software Company Somewhere in the State of Washington. His background was in BUFD (big up-front design) and he therefore approached this Scrum project (in .NET) with a great deal of skepticism. Read about his conversion here. He also gives an example of test-driven development and talks about why he's now a believer...so much so that he's uncomfortable writing code before he writes the test(s)....and how (at least in this example) it was a time saver. (YMMV, of course.)

An interesting idea:

This doesn't solve the problem of some clients requiring large functional specification documents, but it does offer at least one potential change to the way they're written: the functional specification can be written AFTER the majority of functionality has been developed and delivered. This is a huge step toward an accurate specification and it also drastically reduces the amount of time it takes to write the document.

On Being Agile

As you've worked on or with teams making the change to more of an Agile Software Development approach, you've probably heard comments along the lines of, "Hey, this is just assigning a name to what we've already been doing." -or- "These are all just common sense concepts.".

As we coach teams on adopting Agile principles we try to respond to comments like this confirming that yes, Agile principles mostly represent filtering out activities that don't seem to be useful (at least not in every situation) and doing more of the remaining activities most of the time. These activities (or Agile principles) tend to be the items that people list as being useful to deliver working and testing code on a frequent/consistent basis. These also tend to be the elements that people list as existing on teams they've worked on in the past that they viewed as successful.

We encourage teams to not get bogged down in calling the process Agile (or not) but to just focus on identifying and alleviating their software development pains by applying principles that may or may not be a traditional part of one or more Agile methodologies. It goes without saying that every team and situation is different, so one way to view Agile principles is that they provide a framework of useful concepts that you can introduce (gradually in some cases) to attempt to fix a broken process. Some of them will be common sense (depending on which team member is viewing them), some fill in holes in a current process that isn't working and others add "just enough" structure to provide useful metrics and oversight for management and all stakeholders.

So on the topic of being or becoming Agile, the debate shouldn't focus on "installing yet another methodology". It should focus more on identifying and admitting process pains and deciding which principles (and how deeply you employ them) will be useful to begin addressing the pain.

Size, Layers and Intuition

As the holidays approach and the cold weather begins moving into Kansas City, it's a good time to reflect on our efforts and goals in the areas of custom software development and agile process coaching.

In the area of User Story Points estimation we made one seemingly subtle change in that we refer to the activity as "Sizing" a User Story rather than "Estimating". For us, it seemed to further focus the discussion on the size of a given User Story, especially when triangulating the story relative to other already-sized stories. This has been useful in a variety of ways, including helping move people past struggling to understand the concept of a story point.

We look at discussing and sizing a story in terms of the elements common to most stories (at least in terms of our software development) which tend to fall in the area of the classic three layers: UI, Business and Data layers. Traditionally, teams have relied mostly on free-form discussion and developer (sizer) intuition to determine point values and during triangulation. While we agree that expert developer opinion and intution is highly valuable, sessions can sometimes be prone to thrashing (excess discussion), fatigue and personality dominance.

When we conduct sizing (using the Planning Poker approach) sessions, we read a User Story card and then the customer answers questions from sizers (developers) until there are no more questions. This is fairly standard in most Planning Poker approaches. But instead of sizers flipping one card to reveal their overall size opinions, they use three cards. One for the UI layer, one for the business layer and one for the data layer. The idea is that since they are already thinking about the complexity and therefore the amount of work involved in implementing a user story and since they usually do this in terms of design,testing and development along the lines of the three classic layers of UI, business and data, we have them assign story layer point values (using the same point scale they would for overall story points) to generate discussion about differing opinions and to confirm assumptions even when their size opinions are similar the first time they flip their cards. In some cases, we'll even have the sizers shout out the objects (Forms, Reports, Classes, Controls, Tables, Stored Procs, Views, etc.) they had in mind across the layers and record those on the wall for a number of reasons, including for reminders of effort we already accounted for in sizing other stories. The resulting layer size opinions and object counts help with triangulation for an overall story size opinion. This is useful for current sizing sessions and for future triangulation as new stories are uncovered during subsequent iterations. The final consideration is developer (sizer) intuition. Even with object counts and layer assumptions in place, if the group feels that similar stories based on the above shouldn't share the same overall point assignment based on their gut that design, acceptance testing, etc. makes the story belong in another point column, then the story gets moved.

Doing the above does add some additional time to the sizing session but it also saves time by reducing thrashing and directing a portion of the discussion along the lines of the story layers. The net result is no more time is taken and a there is typically a higher degree of confidence in story sizes.

Agile Conditioning

Visionpace recently conducted another ScrumMaster Certification course and a few of our associates participated as well students from other organizations. (If you’re not familiar with the course check http://www.visionpace.com/developereducation.html.) The Visionpace folks have been engaged in agile development (XP and Scrum) for anywhere from one to three years as developers. This training allowed them to consider the agile development from the Scrum Master perspective. As such, it generated a lot of good conversation over some recent lunches.

One such topic that I think is universal to all learning, is that one can’t go to a training session and then expect to be fully proficient at the end of the training. Nor can one go to training and not use the skills presented in the training, and expect to retain them. In order to become proficient in a new skill set (be it a new language, new technology, new art form, or new project management approach) one has to continuously use, hone and train with the skill set.

This was the topic of conversation recently. It seems that a lot of people expect that if they send a person to a class and\or have them read a book that they will then be an expert in the topic overnight. (Does this sound familiar? “Jetson, we’ve been hearing a lot about agile development lately and figure if it can work at Chrysler it can work at ACME Sprockets. Attend this three day seminar next week and be ready to tell the Board what we need to do when you get back.”) It’s not unlike your boss telling you to go home over the weekend and read a white paper about swimming and spend a day or two at the pool swimming laps because you’re going to be the captain of the new company swim team. In order to be proficient at anything, you have to train. You have to condition yourself for the skill and continually build on it.

At Visionpace we strongly believe in the phrase ‘Inspect and adapt’ as part of this continual conditioning. Collectively and individually we look at our project and the associated process to see what we’re doing well and what we need to address. We have regular reviews and sessions to help each other get better at being more productive team members.  This is good because it allows us to review and reinforce our actions and processes. Over time we find the results continually improve and as one would expect proficiency increases. A simple concept, that often time is overlooked in organizations.

Heartland Developer Conference 2006

Bud Wheeler just sent me this excellent overview of HDC 06. Bud is a seasoned developer with Visionpace doing custom software development in Kansas City, with a focus on Microsoft technologies and agile software processes. Thanks Bud!

I just returned from the Heartland Developer Conference (HDC06) held in Omaha Nebraska. If you aren’t aware of this conference I strongly suggest that you look into it next year. It has to be the best value of any conference I have ever attended. It was a well organized and top notch production.

As I understand it this is a roving conference and has been held in a different city every year. This year the conference was held at the Qwest Center which is a great facility that easily handled the needs of vendors and attendees. There were over 500 developers at this years sold out event. Look for information about HDC07 to be out in December or January.

The conference was split into three tracks labeled Think It, Server It and Store It. I found myself in the Serve It track for most of the conference. Of all the sessions I attended the things that really excited me were XAML and ATLAS/AJAX. These technologies look to be very cool and I am going to spend some time over the next couple months playing with them.

The great thing about a conference like this is that the excitement is contagious. The speakers are evangelists for the technologies they present and it is hard not to absorb some of that excitement. What a great way to recharge the ol’ batteries. We too often get caught up in the daily grind of development. It is essential to take a step back and look at the bigger picture. As developers it is our responsibility to not only provide solutions for our customers current business problems but also to look at the future business needs. Developer training is a big part of that and I encourage every developer to spend some time looking beyond their current tasks. For me the chance to talk to other developers is as interesting as the sessions. The opportunity to discuss how they are solving problems is a great way to pick up new ideas.

To paraphrase one of the speakers, software developers are the only professionals that are trying to solve constantly changing problems with a constantly changing set of tools. How are you going to keep up with that if you are not doing something to educate yourself?

Want to Build Better Software? Better Teams? Build Trust by Putting People (including yourself) at Ease.

Last night, at AgileKC, an agile software development professional group in Kansas City, our discussion began with writing the word 'trust' on the whiteboard. A couple of hours later, we had covered a lot of ground and one of our members finished at the board collaborating with the group to help him generate ideas for an upcoming column he's writing which will mostly focus on 'Agile Smells', identifying symptoms of and suggesting remedies for software development team and process issues. Not surprisingly, 'trust' was a recurring theme during that discussion as well.

We started AgileKC approximately one year ago and these meeting formats tend to be my personal favorites as the ideas and perspectives are openly shared and discussed and I always walk away with useful things to include in Visionpace agile pursuits. Next month we'll have a format where we'll meet in a private room at a local restaurant and sit around tables informally discussing a variety of topics and enjoy a meal in addition to hearing a more formal topic presented by a member of the group. In my experience attending professional meetings over the years this is by far the best format for maximizing learning and networking.

So back to 'trust'. I stumbled across a post on an XP list I'm on that referenced a video featuring Kent Beck discussing, 'Ease at Work' which among other things, related to the softer or more personal side of software development teams, including accountability, responsibility and of course, trust. I think there's a lot of valuable overlap with last night's discussion and as always, Kent shares a number of useful perspectives.

Here's a link to one review of the video on Reblog. You can view the video on Google Videos and YouTube.

The problem with percent-complete

Does this sound familiar? 
PM: “Jason, what is the status of the XYZ Modulator?  Last week you were at 55% and management is breathing down my neck.”
Jason: “Well, I implemented the auto-reload, and the changes from QA. I’d say were about 70-75% done.”
PM: “Great 20% more than last week!  That will make the Powers that Be happy.”
… One week later …
PM: “Jason I need an update on the project status.”
Jason: “Uhhh, yeah about that. Well I found that the auto-reload didn’t work for have the new data types so I spend the last week fixing that.”
PM: “Oh.  Well what should I put as the percent complete? It’s 75% now.”
Jason: “Ummm, how about 80%...???”

When I witness these conversations, or hear about them, I see red flags everywhere.  Percent complete seems to have taken a life of its own outside a Gantt chart.  It has become, in some instances, the measure of all work.  Don’t get me wrong. I think it’s valid to say that we are X% to implementing a piece of functionality provided you also include a reference to a percent complete of what you’re measuring.  (I.E “We initially thought this was going to take 30 hours. That’s still valid and were about 50% there.” From this, one can deduce that about 15 hours have been worked on the code, and about 15 hours remain.) 

One problem with the initial, and far too common, example above lies in not having an underlying measure to use as reference.  If you don’t have some reference included the use of percent complete gets clouded.  Even trying to say ‘I’ve been working on the code for the last three days and I’m 60% through’ leaves some information out of the status.  Were you spending all of your time for the last three days on the code, or were you working on other tasks as well?  What are the plans moving forward?  Are you saying that you anticipate being done in two more days?  In 16 hours?    You’re 60% of what?

Another problem is using percent complete as the only measure of progress in a project.  By updating percent complete as the only means of a project metric, a project can appear to be progressing all the time at a steady pace when its not. The risk is that a culture can develop that the developers are conditioned to give some number greater than the last number they gave for percent complete.  Unfortunately for the developer, the number can’t go above 100%.  So what usually happens is a feature is started and the developer spends say two days working on the feature and feels that they are making good progress and say at the first status meeting that they are 30% (or some other optimistic number) complete.  The next two days they find that they didn’t account for a needed architecture originally in the first two days, so they spend the time implementing it. In the larger picture, in terms of having the feature implemented, they are at the same place as the last status meeting, but have a better architecture.  Since the metric is percent complete, not updating the metric would indicate that they didn’t do anything for the last two days.  So they have to give a number to justify their efforts.  So they choose a number like 15% and report that they are now 45% complete.  You get the picture.  Before too long the status chart shows the code at 80% complete, and in terms of hours spent to date over the overall amount of hours forecast, the number is much less than 80%.  Usually the percent complete starts to increase much more slowly; in increments of 1-5%, until the measurement is finally reset.  Eventually the reporting becomes a dance that everyone feels they have to perform, but nobody on the team has any faith in it. Unfortunately the memo to the executives is seldom sent…

It doesn’t always work out this way, but often I find that projects that rely on percent complete do so because management likes it.  It’s an easy thing for management to understand.   In addition the management in question often hangs their hat on the number and holds it to assumed (and often not-discussed) standards. 
Some of these standards include:
- If you’ve spent time working on the project and the percent complete didn’t increase, you didn’t provide any value to the project. (As described in refactoring example above.)
- Percent complete shouldn’t go backward.  If a house if 50% complete this week, it won’t be 40% complete next week unless some outside factors are in play (like a wind storm.)  Software development doesn’t work like this.
- Percent complete will increase at the same rate during the entire project.  Reporting that the project is 20% complete after two weeks often times allows people to assume that the project will be done in eight more weeks. 
- Percent complete is perceived to always be accurate.  If you say that you are 86% complete, it is assumed that there are empirical calculations to back that up.  Often times, the only thing to back the number up is the number a developer pulled out of the air during a meeting.  Even worse each developer throws out the number for the things they have been working on, so there isn’t any consistency between the metrics for the different tasks the team is working on.

This is why Visionpace follows the model of forecasting pieces of work in ‘story points’ and then when we start working on a specific feature, we break the feature into tasks.  The tasks are estimated in hours, and ideally the entire team is involved in determining the estimates.  This allows for multiple viewpoints and voices, and tends to create more realistic estimates.  As the tasks are worked on the status meeting focuses on:
- What did you work on yesterday (how many hours did you get to spend working on the task)?
- What are you going to work on today (how many hours are left on the task at hand)?
- What are the roadblocks, if any? By asking these questions regularly, the entire team is involved on all of the development.  Tasks that are underestimated initially are identified quickly and the factors that led to the underestimation are presented to the entire team, so they can be understood for the next estimating session.  Additionally, with this approach, if a developer is struggling with a task, it is apparent to the entire team and assistance can be addressed sooner rather than later.   One final benefit of measuring the tasks in hours, is that it’s easier to plan on when the tasks is expected to be implemented.  (Consider the statement, ‘I think there are six hours remaining on this task. I’m out half a day tomorrow for my kid’s doctor appointment, so I expect to have it done before lunch the day after tomorrow.’  This explains in succinct detail, what is going with the task.

If you’re interested in this approach feel free to contact me at Visionpace. We deliver custom software development following agile principles in Kansas City.   

What’s your Bus Number?

I really like when an idea can be illustrated simply and effectively in a simple term, one that everyone can understand. I recently came across one of those terms on the web and shared it at the AgileKC group last night.

The term is ‘bus number’ as in “What’s the bus number of this project?” The underlying idea is how many people need to be removed from the project (walk out in front of the proverbial bus)  before the project is in jeopardy. If you have one developer who is the only person that can only work on a specific part of the code, and a hundred developers that can work on everything else, your bus number is one. If every developer can work on every aspect of the code, and you can reasonably bring new developers up to speed on all aspects of the code if needed, you can answer the question by saying, ‘There aren’t enough busses in New York City to affect this project.’ (Swaggering while walking away after saying this is optional.)

The goal is to have a very high bus number, or said another way have a lot of code ownership in the project. But code ownership might be difficult for everyone to understand. The concept of a bus number isn’t. The context of the conversation last night was in relation to pair programming. The proposition I was making was that pair programming is an effective way to increase the bus number on a project.

I don’t know if there will be a big visible chart in our war room for bus number in the near future, but if I come across a project that code ownership (or the lack thereof) can cause a spectacular failure (ala Scott Ambler) I think I would create a chart on a 3ft. x 3ft. piece of paper that had the title Bus Number, and have one element, the project’s bus number. It would be effective in generating the appropriate conversations and would most likely put focus on resolving the issue.

So what’s your bus number?

Interview the the father of Java: James Gosling

Canadian-born James Gosling is the father of Java.  Recently in Canada speaking at a Java conference, the Sun CTO spoke for an hour with Dave Ebner of the Globe & Mail.  The interview goes through James' surprise that Java took off like it did how North America is lagging behind the rest of the world in telco services (he uses Japan's NTT DoCoMo as an example of doing it right).

A short, but interesting read that gives some insight into an amazing piece of computing history.  Java.

Tags: James Gosling, Java, Sun, Sun Microsystems

Ruby on Rails moves to 1.1

Ruby on Rails (RoR) is another of those hot development topics right now.  I've used a few Ruby based applications and have been generally impressed.  The main benefit of RoR is the ease of deploying AJAX (COMET?) apps.

The Web Services Journal and Internet news cover this new release of Ruby.

From the Web Services Journal, here are the what's new in RoR1.1:

What's New In Rails: (complete list here):

• RJS - Write your Ajax application's Javascript in Ruby
• ActiveRecord++Rails' ActiveRecord is a powerful, automatic Object/Relational Mapping tool.  It gets a major steroid boost in Rails 1.1.
• API Support - Adding an API for your Web 2.0 software is now even easier
• New Integration Tests - Rails understands testing and adds even more automatic test support
• Backwards Compatibility - Even with 500 new changes, old Rails apps will almost universally run in Rails 1.1

Like my previous post about COMET, these new development platforms are pushing applications to a new level of development/deployment speed and user interactivity.  Exciting times!

Tags: Ruby on Rails, Ruby on Rails 1.1, RoR, RoR1.1

Catching the tail of COMET

From the Irish Developer Network I found this very thorough description of AJAX's next phase--COMET.

The article goes into detail (not too much) on the architectural differences between AJAX and COMET.  The main benefit, and if you've tried any of the online apps below you've seen it yourself (I like the GMail-GTalk integration myself), is that COMET is more persistent with long-term connections.  Activities that take time to complete.

• GMail’s GTalk integration
• Jot Live
• Renkoo
• cgi:irc
• Meebo

So the question is, should more apps be moved online via AJAX or COMET?  I'm not so sure.  I still live in an online-offline world, so I need applications that run when I'm not connected.  That being said, I see a lot of potential for internal applications like expense reports or maybe even group spreadsheets and word processors.  Even an internal IM system might be a good application.

What do you think are the AJAX or COMET apps that have the most potential?

Tags: COMET, AJAX, web development, online applications

When the story doesn’t fit

On a recent .NET consulting project in Kansas City, where we were doing software development and agile project management coaching, the team was struggling with sizing our user stories to fit our iterations.

Invariably during our projects we find that some of the user stories we came up with during the initial story workshop don’t really fit in the project development as written. Sometimes they are too large for the time allotted and/or have some high priority tasks and some not so high priority tasks. Other times we’ve learned so much about the project, the initial story doesn’t encompass all the facets it should. The question is what to do with these stories. Should the entire story be tasked out and carried over to the next iteration, should only the necessary tasks be focused on, and the story carried over, or should the story be broken down into smaller stories?

The answer, like a lot of answers when following an agile approach is; it depends. One can make an argument for any of the scenarios listed. Since I’m the kind of person that has a ‘I want to show progress on the burn down’ perspective, I prefer to break the story into smaller stories that ‘slice the cake’. (The stories aren’t all user interface or all back end processing. Rather they have some user interface, some middle tier logic and some back end processing.) What’s important is to capture the stories based on the current understanding, scope them in an appropriate size as much as possible so they don’t have to be broken down again later, and make sure that nothing falls through the cracks.

Once a story is broken into new stories the next thing to consider is how to forecast the new stories. Often times there is the desire to say that since the original story was forecast as a five points, and since we broke it into three new stories, one story that is three points, a second story that is one point, the remaining story must also be one point (5=3+1+1).  Don’t do this.  Another pitfall is for the team to say “When we started these stories would have all been threes, but since we have a better idea about what we’re doing, they all look like one’s now.” The key is to forecast each of the resulting stories independently and triangulate them against the existing stories for the project, making sure they are put in the right bucket.

The take away is to make sure the user stories reflect what you are doing in an iteration rather than trying to make the iteration fit the stories defined. If this means that some stories need to be removed and rewritten, do it. Just pay attention to the stories that are created to make sure they will fit in the future and that you don’t lose anything in the transition. Also remember that the forecasting for the stories follows the same triangulation used in the original story workshop.

Software Inventory

How much money will the organization make or save by having a new software feature in use?

The process of prioritizing the selection of proposed software features based on business value and determining the business value of software features can be as much an art as science. Beyond the more obvious examples of forecasted new sales or cost reductions that some software features somewhat easily map to, most features and their underlying business value are harder to determine.

Return on investment (ROI), Payback Period and a number of other approaches attempt to assign a tangible value to software features for purposes of making decisions on what to build next and in most cases, entire projects or release items. While these methods do work in a number of circumstances and are getting better in aiding business value prioritization, often times it comes down to the intuition of business domain experts. The people that are closest to the business problem the software features support can often see the value of a feature, at least relative to other features.

Having done software development and consulting in Kansas City for some time, one of the most important points of analyzing the business value in our opinion has been to have the discussion in the first place. Regardless of the analysis and approach used (ratios, intuition, etc.), merely spotlighting the need to make decisions on software features to build based on the value they'll add to the business (and how soon they'll add it) is a significant positive step. Another important point is to continually revisit the value discussion throughout the project not just in the beginning. Learning is a part of any software development (or any R & D process) project and a lot can change and be learned during the course of development efforts. Learning also takes place as business stakeholders see software features in action so getting working, tested features in at least a staging area to promote feedback is important to revisit business value discussions. Having business domain experts (armed with the latest intelligence about their domain [market changes, organizational changes, etc.]) reviewing features is critical for moving software out of inventory and into the business and adding value.

Take a look at your software inventory. Some say that any software development item not being used by your customers/users is considered to be in inventory and therefore doesn't have any real (tangible or intuitive) business value. Some items such as certain project artifacts (documentation, models, etc.) will never leave inventory status so carefully decide their importance in understanding what needs to be built or perhaps create throw-away artifacts, spending just enough time to reach an understanding about a particular issue and moving on.

The goal is to put things in inv