I’m certainly not the first to say it, and I’m sure I won’t be the last. The software/Internet world requires focus as much as any other industry, if not more.

The number of platforms, technologies, and frameworks has been growing at an amazing pace. Nearly every month Amazon announces a new web service that adds to their cloud computing arsenal. Google has also recently announced Google App Engine, an entire framework to build scalable web applications.

Every time one of these new technologies comes out, I’m tempted to write something to utilize it. I would get the benefit of learning something new and exciting (which is often worth some of my time), but I have to remember to remain focused. Focus doesn’t mean ignoring what is out there, you obviously have to be open to new ideas and knowledge. Focus means spending the majority of your time on a single goal, to make something amazing.

If you want to write a successful piece of software simply fill a need. There are plenty of gaps in the software that is available, and what is currently needed. To reiterate:

1. Identify a need
2. Fill that need well
3. Fame and fortune

What prompted this post? Right now, I own 18 domains. There are about 5 of them that I’m currently juggling, and it’s not not working. I used to manage about 10 of them, and I had to make cuts. It’s time to start cutting and consolidating again. I can only realistically maintain 2-3 sites. I’m sure a lot of my readers are in the same situation.

How do you figure out where to focus?

• If you don’t have Google Analytics set up on your sites, I highly recommend you set it up. It’s free and easy. I now have it set up on all of my sites, and it’s helped me see which sites are not very popular.
• Ask yourself what your talents are, and think about where they are best applied. I’ve thought about starting a lawn mowing business because it looked like easy money. The problem is that it doesn’t use any of my talents. Your talents are what will allow you to create something truly amazing.
• Choose projects which passionate users. Passionate users are usually going to be your best customers, and they’re very hard to find.

Once you see which projects you should be working on, do yourself and everyone else a favor. Focus your time and energy on those! Nearly every successful person I’ve spoken to says that to be successful, you need hard work and persistence. None of them have said to spread yourself thin.

In this post I’ll talk about a few ways that you can deal with the common influx of requests that come in for a software team.

I used to work for a large company affectionately known at the Borg. I was fortunate to work in a division of the company whose product was a software package. This essentially meant that I worked for a software company.

My current employer is a mid-sized business, and we’re not in the software business at all. My primary job function is writing custom software for certain customers, as well as creating the "glue" that holds together the software packages that we have purchased.

Luckily, we’re a growing company, so we’re starting to have a real software development team. With that comes with the pains of getting organized, and making sure we’re working on the right projects.

What do you do when the amount of work being requested from management greatly exceeds the amount of work your team can actually get done?

1. Push back – This doesn’t have to be negative. The person requesting a new software project might not understand that you’re team is busy. It’s common to think of an IT department as overhead. They are usually not factored into the costs of new projects. A good manager will be able to explain the situation, and either delay the request, or drop it completely.

2. Set up monthly meetings with the key management members - This gives people a forum where they must discuss the work they’re asking to be done. At this point, a good percentage of the work could disappear, because no one is willing to try to justify the importance of their project.

   Some of the projects that would normally be high priority are now not as important when compared relatively to all the work that needs to get done. This also gives management members time to negotiate directly with each other, and you won’t be caught in the middle of it.

3. Create a visible schedule of tasks that need to be done – When a member of management wants their work done, they can look at the schedule and see that they are not alone. If they want something done, they may have to negotiate with someone that is already on the schedule. If they can do that, they probably deserve to be on there.

4. Associate a cost with all work to complete – For any tasks that take longer than, say, 2 hours, require that the time be charged to a particular task. That time can then be equated with money. Since your time now has a set cost associated with it, people that need your time will have to pay for it. Actually money doesn’t have to be exchanged, but just associating costs will put the burden on the person requesting it. If they have to justify $100 worth of time to save $50, they might think twice.

Do you have any other tips for dealing with this situation?

Every since reading Joel’s article “Painless functional specifications – Part 1: Why Bother?”, I’ve be a big fan of writing functional specs. I’ve done it for a few projects, and I’ve encouraged others to do the same. The biggest reason is to solve problems ahead of time, instead of waiting last minute.

Then, I start reading about the LEAN philosophy, and it’s telling me to not plan anything, do what you need to do, and change as the customer makes requests, or as you learn what the project really needs. What??? How the heck is that supposed to work.

I think the answer is a hybrid approach. Write your spec document, but don’t try to design your entire program before writing any code. Solve the overall issues that you know need to be solved, and also plan any features that you are absolutely sure you will need. The spec document should be a snapshot of the bare bones version of what the software needs to look like.

The problem with Joel’s approach is that it assumes that the customer won’t change their mind, and if they do, they’ll be able to get all of it out of the way before any code is written.

I’ll give you a real life example of a project I’m working on. The project was extremely rushed to get the first version out the door. Because of a lack of planning (I wish we had a spec!), we had to throw a lot of our work away and start over.

The lesson learned was that we needed better planning.

However, once the site was live, we realized that we didn’t really understand what the customer wanted. We needed to look through our statistics and get customer feedback before we could attempt to plan future features. The result is that we try to plan our features is detail, but we meet every week to prioritize them.

If we were to formally plan the next version of the site, and then code it for a month, I believe the results would be a disaster. Because we are constantly learning, we need to be able to adapt to changing conditions quickly.

If we were to plan another major release of the site, I would advocate creating a detailed spec, but try to minimize the size of the release as much as possible. Release early, and release often.

I know that Joel is against the “release early, release often” mindset. The truth is, it highly depends on what kind of software you’re writing. Joel is writing Fogbugz, which is already very popular, and has a great set of features. They can afford to take their time, and they probably have a good understanding of what the customer wants. If you’re not as fortunate, you may just have to put something out there that isn’t perfect, learn what users want, and adapt quickly.

The company I work for has recently started a major LEAN manufacturing initiative. When I first heard about it, I started having flashbacks to the Six Sigma training in me GE days. While the concept of Six Sigma makes sense, the approach that GE took was completely useless.

Fortunately, LEAN thinking actually makes sense to me. The basic philosophy is optimizing what you have by eliminating all forms of waste.

So can LEAN be applied to software? I believe it can be applied in at least two broad categories.

LEAN can be used before you even write your first line of code. You need to ask yourself if it even makes sense to write the code. Software engineers such as myself often see the answer to all problems in code. It’s like the saying “if all you have is a hammer, everything looks like a nail”.

Instead of writing the software yourself, evaluate if there is an existing product that will accomplish the same goal. If not, try to break the problem down into smaller pieces, and see if there are existing solutions that may eliminate or minimize the number of pieces that need to be built.

Obviously you’ll have to weigh the costs of custom code against the costs of integrating a third party product. When doing so, be careful to not simply compare the amount of time coding. Every line of code will need to be debugged, supported, quality checked, version controlled, and successfully be part of your overall solution.

Once you have made the decision about what code you are actually going to write, you have now entered the second category of LEAN software thinking. You now need to optimize the actual development process. There are several methodologies that attempt to use this philosophy, such as Agile programming.

I’ve ordered a few books from Amazon so that I can more familiarize myself with Agile and LEAN programming thinking. Stay tuned for some more in depth posts.

One of the best ways to speed up the development of that project you’re working on is to use third party libraries controls. In particular, .NET has had an absolutely amazing number of third party controls. Microsoft has made it amazingly simple to build re-usable code.

Buying third party controls will allow you to focus on your unique functionality without reinventing code that others have already planned, tested, and are maintaining.

Here are the top things that I look for, in no particular order:

1. Does the author have a demo page or application? If I’m looking for a type of control with a lot of competition, I’ll use this to immediately exclude some of them. If you have a unique control and I don’t have many options, I’ll probably still check it out, but you better hope I can set it up quickly.
2. Is the control reliable? Can I break it? Once your software goes out, the users are equivalent to monkeys in many respects. If there is a bug in a control you’re using, they’ll find it. I would rather not have to deal with that, so I take a good look at reliability.
3. Does the control play well with others? Some control manufacturers build amazing controls that work great with the other controls they sell. The problem is, if you mix and match, they often don’t play well. With ASP.NET controls, take a look at the rendered output and make sure it’s elegant and well thought out.
4. How much does it cost? This is obviously going to factor in different amounts based on your project and situation. If the control costs less or more than you expect, try to figure out the root cause. If it’s expensive, I would expect amazing support and documentation. If it’s cheap, I would make sure that it’s because the control focuses on doing what it is supposed to. For the price, the control needs to save me time, which should translate into savings for the project.
5. What kind of support is available? Great support can make up for a lot of shortcomings. I’ve used controls that were buggy, but I basically had one of the control developers holding my hand. They were able to fix it quickly, or tell me what I was doing wrong. Support can come in a variety of ways:
   • Phone support – Is it paid or free? If you have to pay, is it per incident?
   • Email support
   • Forums with support monitoring – How actively monitored is it? Have everyone else’s questions been answered.
6. Is the author going to be around tomorrow? If you want to be able to get updates or support, will the author still be around to provide them?
7. Does the control take over my computer? I don’t like controls that are much more than a DLL, or a set of files. I don’t like having to “install” your control on my computer. If it’s difficult to install, the probably means it going to be difficult to figure out how to deploy it. I want XCOPY deployment. I don’t want to mess around with GAC registration and manual licenses.
8. Is the license overly restrictive? Many licenses require your first born child to use them in a real world. I prefer a license that lets me use it in pretty much any way I want. That’s why I’m spending the money. I don’t have any problem with tiers (per site, per server, etc). If you do have licensing tiers, allow me to upgrade and pay the difference. I also want to be able to have all of our developers actually compile the code without having to buy additional licenses. Some controls require a license for each developer, regardless of whether or not they’re working on the feature that uses it.
9. How much are upgrades? I have seen a few controls that offer free upgrades for life. Personally, I’m about twice as likely to buy those. Not having to justify paying for an upgrade is great. Companies like to buy things and forget about them. Even if it’s not free to upgrade, it’s nice getting good discounts for being an existing customer.
10. Is the control easy to use? This is obviously critical since you’re buying the control to avoid having to write the functionality yourself. If it takes 10 hours for you to write the code to use the control, and it would have taken 10 hours to write everything yourself, you probably haven’t gained anything.

Here are some great places to get started:

• ASP.NET Control Gallery
• WindowsForms.NET Control Gallery