SILC - Solution Implementation Life Cycle

Hosted Source Code Control Solution

Brian Lanham — Fri, 31 Oct 2008 13:49:58 GMT

I understand that CollabNet has a hosted version of Subversion but their site is a tad confusing in this regard. Anyone out there recommend a hosted source code control solution?

The Cini Mini Syndrome

Brian Lanham — Sat, 02 Aug 2008 16:40:51 GMT

Many years ago I purchased my first house. One of the first morning's in the house (a Saturday I believe) my (ex) wife fetched breakfast at Burger King while I continued installing child safety devices. She returned with baked, unhealthy yet totally tasty and satisfying treats from the King. Among the choices was a box (or two) of Cini-Mini's.

I stared at the box quickly becoming fascinated with the design. I have always been a curious type. Also, I am a process geek. I am interested in learning about how things are designed and built. Although I was just finishing college, I was already feeling the frustrations of poor / no process. While staring at the box I started pondering the design.

I can't seem to find an image of the box so my textual description will have to do. Things I noticed about the box:

1) Graphics - The graphics on the box (such as the Burger King trademark logo and the name of the product) are printed at an angle with respect to the sides of the box.
2) Size - The container is designed to hold precisely 4 miniature cinnamon rolls. The cinnamon rolls are an unusual size for cinnamon rolls. The icing container holds enough icing for the four cinnamon rolls. (It's actually a little more than I like.)
3) Layout - The container is designed to provide a space to house a single container of icing. As such, the icing containers are not part of the box and, instead, are inserted into the overall container at purchase time.

While standing there observing these aspects of the container a thought occurred to me that has stayed with me over the years.

"More design time went into this box of Cini-Minis than into most software systems."

Does that make anyone else sad? If you think about it for a minute, you can see the Vision document forming in your mind…

1) Sales & Marketing - If we put the graphics at right angles to the container then we can get as many graphics on a single container. Furthermore, angular graphics are more catchy than perpendicular graphics. At what angle shall the graphics be printed?
2) The Food Itself - How many rolls shall we put? This one is great because it drives EVERYTHING. They must have conducted some research into approximately how much food a test group consumes. How much icing is consumed with the number of rolls we've chosen? Do we need to redesign the container for the amount of icing?
3) Preparation - Is the size of the roll conducive to our existing kitchen equipment? How long does it take to prepare this item?
4) Shipping - Let's put the icing in the container at purchase time. This way we can flatten the containers completely for shipping. This also allows us to ship the containers in a non-refrigerated vehicle.
5) ROI - How much will we charge? Is this amount profitable given the manufacturing of the containers, the food, the size, the marketing, etc.?

Many of these items are business and system supplemental requirements but you can easily play a similar scenario to form use cases. So what's my point?

Cini-Mini Syndrome (noun) - A situation wherein less effort is expended sufficiently planning and designing a business software system than a snack.

Think about the business systems you have in your organization. Did anyone consider integration? Reuse? Modularity? Service-Orientation? Or, instead, did someone throw together a system as quickly as possible and now they spend their days maintaining it by quickly adding new functionality or updating records in the database directly?

The next time you are building a software system, use a simple litmus test. "Do I have enough information to implement Cini-Minis?" Have you before or do you now experience The Cini-Mini Syndrome? What advice do you have for combating these situations?

Free <> Open Source <> Free

Brian Lanham — Sat, 12 Jul 2008 23:14:10 GMT

For those of you who know me, I work very hard to speak very precisely. As such, I become frustrated at the repeated abuse (incorrect use) of terms. Among these, it is my opinion that there is some abuse among the terms "free", "open source", and, well, "free" (yes, I am repeating myself) in the context of software. I am going to provide my definitions for these terms.

Free (in terms of Purchase Price)

There is a lot (and by that I mean A LOT) of free software. Utilities, full-featured product suites, operating systems, database servers, development tools, the list goes on and on (and on and on and on and on...). Not all of these products are, however, open source. So while there are many (many, many) products that are freely available, you won't always be granted access the source code. In summary...

Not all free software is also open source software.

Open Source

This generally refers to software where in the source code (in part or whole) is exposed. There is a common misconception that all open source software is free. Granted, most open source software is, indeed, free. However, there are some for-cost systems whose source is available for a fee. This is not common but does occur on occasion.

Free (in terms of Total Cost of Ownership)

I think it's safe to guess that if you are reading this you know that "free software" is not free to obtain, implement, integrate, and maintain. The costs for each system (beyond the development/purchase cost) is called the Total Cost of Ownership. I won't spend a lot of time writing about this because it probably is well understand.

So that's it, just want to set the stage for my next blog entry. What are your thoughts on this?

Required Features <> Requirements

Brian Lanham — Tue, 29 Apr 2008 18:42:25 GMT

Those of you who know me know that I am a stickler for using the proper word. A shovel and a spade are not the same thing. The term "requirements" is suffering a similar fate. Although requirements have come in many varieties over the decades, the current de facto standard is to capture functional requirements as use cases or some similar mechanism (user stories, for example). Unfortunately, however, I often see a bulleted list of "features" described as "requirements".

Don't get me wrong, feature lists are an important (perhaps even essential) part of the requirements gathering process. They should not, however, be mistaken for "complete requirements". The requirement model is a complex, living organism that consists of significantly more than a simple list of features. The sunny-day scenario is easy (and maybe even boring as a result). You need to expand (GREATLY) on the "feature" to describe the exceptional conditions and situations associated with it.

Use the correct terminology where possible. If you have a list of "things the system ought to do" in Excel(R), do not mistake that list for requirements. On the other hand, don't throw it out either. This feature list is an important part of understanding the features that the system must provide to be effective at automating some business process. But it is only the beginning of understanding.

So, if you were to look at artifacts created as part of a requirement model, consider the following:

Feature List - This can be on a sheet of notebook paper (yes, I wrote "paper").
Vision Document
Use Case Outlines
Use Case Details
Use Case Diagrams
Supplemental (Non-Functional) Requirements

What's that? Activity Diagrams? Oh don't even get me started on business modeling...

Using Third-Party Components

Brian Lanham — Fri, 18 Apr 2008 18:09:53 GMT

This entry is originally from the Roanoke Valley .NET User Group newsletter.

This month the UG held a luncheon, sponsored by Telerik, about their products. One of the UG members, George Matzko, mentioned the potential pitfalls associated with using 3^rd-party components. In this month’s newsletter I want to discuss that as it seems to be both an important topic and a topic of recent interest.

The Benefits of Using 3^rd-Party Components

· Time to Market – This is arguably the most obvious benefit. If you buy a 3^rd-party component that exposes the functionality needed then you can reduce the time to market for the overall product.

· Maintenance – Instead of you needing to fix defects and provide updates, the vendor does this. Generally, vendors provide fixes at no charge (although upgrades are usually offered at a cost). This alleviates the maintenance burden from your team.

· Research – Vendors are focused on their aspect of your business. Component vendors, for example, focus on their components to provide a discrete yet robust functionality base. This allows you to focus on your core business. Basically, you are buying their research and development effort expended by the vendor.

· Education – Usually 3^rd-party vendors provide sample code for how to use their products. The samples, however, can also demonstrate good (and bad) coding practices. This can be an opportunity to educate your team.

The Pitfalls of 3^rd-Party Components

· Vendor Tie-In – Of course, purchasing a vendor product ties you to that product. If, for example, you purchase a grid control (a fairly common purchase even today) and you use it in several applications, you are essentially bound to that version of that control. You may upgrade to a new version of the platform (e.g. going from .NET 2.0 to 3.x) and the grid is not supported.

· Maintenance Contracts – Larger-scale components can ship with maintenance options. Maintenance contracts are generally priced as a percentage of the cost of the base product. While a 24-hour turnaround time on issues helps, the contract itself can be costly.

· Learning – Instead of learning the intrinsic controls in your platform (such as ASP.NET controls), your team needs to learn the 3^rd-party components. This means that if you hire team members who use the intrinsic controls or components from other vendors, you need to set aside training time for them.

· Upgrades & Testing – Just because the vendor (supposedly) tested their software doesn’t mean you can skip testing in your environment. You need to make sure you have appropriate tests for your applications and that they consider the upgrades to 3^rd-party components.

What pitfalls have you experienced? Do you have success stores for 3^rd-party components? Share your vendor-related experiences with the rest of the NUG!

Happy Alignment!

Buy vs. Build

Brian Lanham — Thu, 10 Apr 2008 19:12:26 GMT

This entry is originally from the Roanoke Valley .NET User Group newsletter.

Buy vs. Build – How to Decide

Last month we talked about adopting new technologies. Related to adopting new technologies is the “buy vs. build” conundrum. You should always consider purchasing an existing system if you can find one that meets the requirements. However, there are occasions when it makes more sense to build the solution. Before making a buy vs. build decision, you still need requirements. Once you have a baseline set of requirements, you can consider Commercial Off-the-Shelf (COTS) products.

Buy vs. Build Considerations

Not everything is as cut-and-dry as we would like. It may seem that you can simply review the features of a range of off-the-shelf applications and compare the features to determine whether or not a product is a good fit. Unfortunately, it’s not that simple. You need to consider other aspects as well. I like to think of the considerations in three categories including functional, non-functional and business.

Functional items relate explicitly to the functional requirements of the given system. Can users attach notes to patient records? Can users reconcile to a certain date? Can users define their own templates? These are often the obvious items to consider and generally lead to a quick analysis. Either the product supports the feature or it doesn’t. There are some exceptions to this, of course, but you get the picture.

Non-functional items relate to the supplemental requirements of the given system. Does it run on my network (e.g. 100MB vs. 1GB Ethernet)? Is it browser-based? Does it have an API for integrating with my existing financial systems? Can I use it with Active Directory®? These items can be obvious but some may be tricky. For example, the system may, print reports but you may not be able to customize them.

Business items relate to the overall business impact of the product. These items are the most often overlooked and yet can be the most costly. What are the base and maintenance costs? What are the initial training costs for both the business and technology staffs? What are the refresher training costs? What is the level of effort associated with installation and (for disaster recovery) reinstallation?

To Buy or Not to Buy…

It may seem obvious that if the TCO for the COTS product is greater than or equal to the cost of building, you should buy. There may, however, be scenarios wherein you should build instead of buy, despite the TCO of the COTS products. While there are several reasons for going against the flow, one of the more substantial reasons is training.

If you can find a low-risk project, consider using it as a training effort. This will allow your team to learn that new technology without adversely impacting the business. What this really means, mathematically, is that you have included the cost of staff training in general in the gap analysis.

Tip: Excel® makes a great gap analysis matrix. You can quickly evaluate various solutions (including building) and quantify your analysis and the final decision.

How do you make buy vs. build decisions? What experiences have you had with your decisions? Share your adoption stories and lessons learned with the rest of the NUG!

Happy Alignment!

Introducing & Adopting New Technology

Brian Lanham — Mon, 11 Feb 2008 19:54:31 GMT

This entry is originally from the Roanoke Valley .NET User Group newsletter.

As we discussed last month, technology is ever-changing. We talked about ways to maintain your skills and knowledge level. It is hard enough to introduce yourself to new technology. However, you’re not the only one who needs the introduction. Roanoke Code Camp 2008 is going to be here in a few weeks and you will be bombarded with all the wonderful newness to come from .NET. Now that you know about the new dewflanchy, how are you going to get your team members and your manager to get on the bandwagon?

One of the biggest mistakes people make with respect to new technologies is failing to plan for adopting them. You should consider new technologies as candidates for adoption until proven otherwise. I am not saying that every new gizmo that comes from Redmond (or elsewhere) is appropriate for your business. I am, however, saying that when you learn about new technologies, you should consider adding them to your tool chest. Here is some advice for aligning your current technology business with new technologies.

When Informed of Upcoming Technologies…

1. Evaluate – Determine what problems it solves. If it solves a problem you have, consider adopting it. Establish an evaluation plan for the newbie. Don’t just take it at face value. Use a formal project and assign resources to conduct a quantitative analysis. By assigning resources, constraints (budget, schedule) and goals, you improve the chances of reaching an end point.

a. Does it fit your enterprise architecture?

b. Is it a cost-effective solution?

2. Adopt – If you choose to adopt the new technology, create a formal adoption plan to answer the following questions.

a. How are you going to introduce the new technology to the organization?

b. How are you going to upgrade the existing solutions to avail yourself of the new technology?

c. How are you going to start using it in new solutions?

When Learning a New Technology…

1. Educate Others – If you feel the newbie can benefit the organization, prepare 30-60 minutes presentation for your team. Provide a general overview instead of specifics.

2. Prove It – Create a proof of concept or three. Make a sandbox (virtual) environment to start demonstrating some of the features of the new technology.

3. Use It Appropriately – Don’t force it. Look for fit opportunities to utilize the new features.

How do you adopt new technology? What is missing? What questions do you have? Share your adoption stories and lessons learned with the rest of the NUG!

Happy Alignment!

Save Time with UI Storyboards

Brian Lanham — Fri, 01 Feb 2008 20:06:03 GMT

The old adage that 'a picture is worth a thousand words' is never truer in software development than in relation to the User Interface (UI) Storyboard. I am working on requirement modeling today and I am once again reminded of the value that simple storyboards can add to overall requirement modeling.

Even though I know how to build it "the right way", I tend to model some requirements and feel that I have enough information to start designing and/or coding. I was creating a design model this morning for a subsystem and had a lot of detail in it. I started working on the data model, however, and several questions popped into my head.

While trying to answer the question, I repeatedly went back and forth between the requirements artifacts and the design artifacts. It was like trying to get the bubbles out of a carpet. Every time I smoothed one bubble, another appeared in a remote location. Then I started thinking along the lines of "how will the user actual perform this task?" I quickly realized that the problem domain is not as well understood as I had thought initially and that more detail is needed in this iteration.

I spent about an hour creating a simple UI storyboard focused on the question that had arisen. Fortunately for me, it not only paid off to help answer that question, it also raised several other situations I had not considered but that could prove the initial design inadequate.

I was chatting with a friend about UI storyboards and we discussed different tools we use to create them. Here are my suggestions for successful UI storyboarding. By "successful" I mean that you get a big value from a relatively small effort.

In my vernacular, a UI storyboard is NOT a prototype and NOT a proof of concept. It is an organization tool that allows you to preview a sequence of events without expending a lot of effort.

I use Microsoft(R) PowerPoint(R) for most storyboarding.

It offers a wide range of display & visualization tools, navigation options, and deployment formats.
It is generally more available than other products such as Microsoft(R) Visio(R). Visio is GREAT for UI storyboarding. However, as a consultant, I run into a lot of situations where clients don't have Visio.
It is relatively quick. I have a few UI storyboards from past projects on which I rely to provide a baseline. A few changes to the Master Slide and I am off and running.

I have also used other tools.

Visio - As stated above, I like Visio for a UI storyboard tool but I find it is not as common as other tools.
HTML - I have done a few storyboards in HTML. You might think that it seems a very logical choice, especially for Web apps. I find a few problems with it.
- Effort - It is relatively time consuming. Without writing code (such as a Master Page), you will have to redo a lot of work for each page. For example, if you remove a page or add a new page in a multi-page process, you might have to modify "main menu" links on every page.
- Expectations - Viewers have higher expectations. I find that people viewing a PowerPoint presentation tend to have less expectations and, therefore, more ability for abstraction than with HTML. I can only assume it is because they are viewing the storyboard in a browser and, as such, expect everything to "work".
Tear-Off Sheets - I love this option as well. It is extremely fast and provides virtually immediate feedback. I actually start with these when in a group setting and then migrate to a digital format.
Whiteboard - I love whiteboards too but they don't have the permanence that tearoff sheets have. This is why someone put a camera on your phone!

Don't skip storyboarding. In fact, if you don't feel like opening Word(R) and typing, create a storyboard. If you are new to storyboarding, you will be amazed at how many questions are answered with relatively little effort.

Role on Project <> Job Title

Brian Lanham — Tue, 29 Jan 2008 02:34:42 GMT

I don't know if I'm more sensitive to it these days or if I am just hearing it more, but there is a definite problem in managing human resources on technology projects.

It seems that with increasing regularity (or I have been living under a rock), people are assigning roles on projects based on the job titles of team members. For example, suppose you are hire someone to fill the position of "Business Analyst". Now let's also suppose that the new hire is a programmer as well. That is, this new hire has both business analysis skills as well as programming skills.

Let's say that this new hire is assigned as a Business Analyst for the Accounting department. Now say a project starts and this person is added to the project as the business analyst. It is not uncommon these days to hear "well we don't need a developer cuz that new person can write code."

WHAT!?!?! As crazy as it sounds, I have seen very similar situations. Of course, the roles and titles are different but the gist is the same.

While it's true that there are situations where we have to wear multiple hats, it is important to make sure this is done appropriately. Some roles require objectivity that is compromised by wearing multiple hats.

Developer & <anything else> - Developers, like all humans, tend to migrate toward their comfort zone when the going gets tough. This means that whether or not requirements are well defined or design is complete, when the schedule gets tight (and it will), the multi-hat-wearer will start writing code. And we all know how this turns out...
Project Manager & <anything else> - Seriously, the PM should really be too busy to produce business model documentation.
Subject Matter Expert & <anything else> - There seems to be a tendency to have the SME participate in various roles. SME & Business Analyst. SME & Tech Lead. and so on. The SME is, practically by definition, almost NEVER objective. (is that written in english?)

So make a list of all the roles needed for the project. Assign people to the roles appropriately based on the following criteria:

Critical Path - Divide the SDLC into major aspects such as Business & Requirement Modeling & Analysis; Analysis & Design; and so on. This is important so that one person isn't responsible for the work that leads to their work. Dig?
Objectivity & Focus - Some positions require objectivity and focus. Developers should have a say in requirements. Project managers shouldn't be testing software. If you think that a person in one of these roles won't be busy on a single project, then have them participate on other projects in the same or a very similar roll. In my experience, it's better to have a PM that is part-time and focused than other.

This isn't perfect, of course. Sometimes we do have to play multiple roles that can (and do) result in a conflict of interest. Try, try, try to keep them separate. Fight the urge to just write code.

I Fought the Artificial Key...

Brian Lanham — Tue, 22 Jan 2008 01:34:53 GMT

and the Artificial Key won.

I don't know what my problem is with artificial keys. I am a HUGE advocate of natural keys. My problem is, I tend to use "natural" keys where one really doesn't exist. For some reason, I am fixated on avoiding duplication. However, I tend forget what is an appropriate duplication and what isn't. Take the following example:

What do I care if someone duplicates a URL? I mean, really...does it matter if the same link is listed twice? It does NOT. Sheesh! I am just killing myself.

So, in the end, had I conducted a little database design I would have never incurred the problem. So the next time you see me blogging about databound controls or database design issues...please remind me to use artificial keys where appropriate. Thanks!