Do programmers need a degree in Computer Science?

Note: this post was originally published on InfoWorld.com.

A recent survey from StackOverflow states that 48 percent of developers never received a degree in Computer Science. But when you look at the requirements for software developer jobs (at least in the Chicago area), it seems that most positions list a degree in Computer Science as a preferred item, if not a requirement. Are these 48 percent of developers without a Computer Science degree disadvantaged when it comes to their ability to perform on the job? My experience -- though with a music degree I'm a bit biased -- is that programmers without a degree in Computer Science can perform better at some technology-related tasks than their degreed counterparts. Why is that?

The mismatch between Computer Science and day-to-day programming

I've interviewed job candidates straight from school who had spent classes performing utterly useless programming activities (like debugging syntax errors in a text editor when free software will do that for you), making me question the value of their degree. Low-quality training is, of course, a problem, but even quality Computer Science programs don't teach the skills necessary to be productive on the job.

Most of the relatively new Computer Science graduates I've worked with had a fairly good overview of how technology is supposed to work, making it relatively easy to explain technical concepts to them. But explaining what needed to happen in order to solve the problem at hand was much harder. In other words, they had a pretty good idea what was possible, but had trouble deciding which concepts were appropriate for a given scenario. It would have been much more useful to me as an employer to have someone with deeper experience in a narrow field and less breadth of knowledge to be more effective on day one of employment.

In other words, it seems to me like getting a Computer Science degree is like learning about how materials used to make a piano affect its sound, response, etc., without spending much time actually learning how to play. But to be an effective piano player, it is much more important to learn to play piano -- to learn to apply knowledge in a useful manner -- than it is to know how a piano is played and made.

Why continuous learning is the most important predictor of success

Many people, after reading the above section, will state that the job of a Computer Science degree is to provide a foundation of knowledge that can be built on later. But this is true for any means of learning to program. Most of the people reading this know that new technologies come out at a dizzying pace. One of my ex-employers stated that technologies tend to cycle every three years, meaning that you should expect to be working with different tools and approaches three years from now. Programmers who can take new tools, languages, and other information and effectively incorporate them into their day-to-day work will be a great deal more successful than those who cannot. I would guess that, all other things being equal, the advantage to having a Computer Science degree for developer effectiveness would be severely diminished by the end of the first three-year cycle, and would be eliminated by the second.

Cultural differences between Computer Science graduates and self-taught programmers

At the beginning of the article, I mentioned that there are some areas in which I've noticed that self-taught programmers perform better than those with Computer Science degrees. That area? Understanding business requirements. I've met some programmers who love to dig into the business problem to get a better understanding of the problem they're trying to solve, and others don't want to be bothered with the messy details and only want to be told what to build. Given that the typical setup for development teams is that business analysts spoon-feed software requirements to the development team, this may not seem like such a big deal. But as I wrote about earlier, poor requirements can derail a project faster than poor coding will, and the best way to get high-quality requirements is to get the people building the software communicating directly with the people using it.

Conclusion

Does this mean that I typically look for candidates without Computer Science degrees? No, of course not. But it does mean that when I look for candidates for a position, I typically look at the degree out of idle curiosity only. Even with recent graduates, I'm much more interested in the side-projects that the candidate has done to apply their knowledge than anything they might have learned in the classroom. Candidates who show an ability to learn new things without being directly taught have an advantage over those who haven't, regardless of their formal education. I wish more candidates and employers felt the same way.

When organizational debt slows software projects down

Note: this post was originally published on InfoWorld.com.

Most companies, when embarking on a major software project, have a fairly good idea what they need to accomplish from a high level. In many cases, though, the business does not know the details surrounding the software project well enough to make it truly a success using meaningful measurements. If you make software for a living, eliciting these details is a normal and expected part of your software development process. But there is one problem associated with software projects that too often gets neglected, but fixing it is a vital part of delivering your software product successfully. I call it organizational debt. To explain what it is and why we should care, I will describe it by drawing parallels to the better-understood problem of technical debt.

What is technical debt?

Technical debt is the term for issues embedded within the code of the software that make it harder to maintain. These issues may not immediately be apparent to a user, but instead are visible to the development team. Examples of technical debt are:

• Different developers working on the project each had their own coding style, making it difficult for someone new to make sense of the whole product.
• The development team put in a complex bit of code that seemed like a good idea at the time, but in retrospect turned out to be a bad idea because it didn't address the root issue. Now no one understands what it is for and therefore everyone just hopes it doesn't break.
• Because of a particular time crunch, the team makes a conscious decision to ignore best practices in order to get a product out more quickly (with the intention of fixing issues later).

Regardless of the cause behind the creation of technical debt, the result is the same – software that is difficult to update without risking breakage in other parts of the system.

How does that compare to organizational debt?

The parallel to technical debt on a company-wide level would be "organizational debt." If technical debt is issues embedded within software that hamper its maintenance, organizational debt would be issues in the day-to-day running of the company that prevent it from operating smoothly. Examples of such debt might be:

• Different departments have their own tools and methodologies to address the same problems, making it difficult for executives to see similarities in order to address company-wide issues.
• Managers create processes or implement software solutions that seemed like a good idea at the time, but didn't address the root cause of the issue and end up creating more problems in the long run.
• Because of a particular time crunch, the team decides to complete a task in a less-than-ideal manner "this time". But that manner is repeated in subsequent tries because no one remembers that the first time was intended to be a one-off situation.

It is important to note that organizational debt doesn't prevent the company from getting work done. Instead, organizational debt prevents a company from getting work done efficiently and effectively.

How does that impede the progress of a software project?

Companies that have a low amount of organizational debt do so because they have a culture that eliminates it on a regular basis. Conversely, companies that have a high amount of organizational debt do so because their culture has trouble distinguishing between value-adding activities and mere busywork. As a result, when they go to build or implement new software, they not only try to implement all of the processes that existed previously, they try to implement all of those processes at once. After all, if they were there before, aren't they vital to the future success of the company?

What can software teams do about organizational debt?

Unfortunately for many development teams, the answer to this question is typically "if that's what the business wants, that's what the business gets." Such thinking leads companies to turn a tangled mess in an old system into a tangled mess in the new one. But smart technology leaders will use the new software implementation as an excuse to create something better. How is that done?

1. Start by reading up on various change management techniques. John Kotter's approach is a good one, but there are others out there. Remember, you're never going to get the technology right if the business isn't ready for it.
2. Always look beyond requests to understand the underlying business value. Business leaders used to creating quick fixes will continue to think in terms of quick fixes for some time. Getting at the underlying business value will help you and the business leader determine what the right solution is.
3. Look for opportunities for consistency. Almost all organizational debt I've witnessed arose because of small-scale solutions to small-scale problems, so encouraging the business leaders to look at the big picture should help.
4. Keep in mind what the big picture is, but focus on small changes. Without the ideal final solution in mind, it will be difficult to keep the project on track. But by delivering changes in small increments, you'll decrease the anxiety levels of the people in the organization who are most resistant to change.

Creating software for companies with high amounts of organizational debt is frustrating because nearly everything is more difficult than a company with relatively little debt. But patience and consistency (usually) win in the end.

Outsourcing a software project? Pay time and materials.

Note: this post was originally published on InfoWorld.com.

Companies that look to hire an outside firm to help them create or deploy new software often will look to pay for that project using a fixed price agreed upon at the outset. This is so they can reduce the perceived risk associated with the project. This is usually the wrong thing to do, though, if you care about creating the best product. To find out why, we first need to examine why software goes wrong in the first place.

Software is almost never right the first time

As I have written before, knowing what to put in your software is more important than hiring great developers in getting your software completed successfully. Yet the industry spends more time finding ways to create better code, not create better solutions. Furthermore, business stakeholders aren't in a position to help. They typically think that they know what they want, and very often think they know how to turn what they think they want into working software. But in reality, knowing how to turn what is usually a failing process into successful software requires knowledge of both the business and of creating software.

On top of that, business needs usually change. Businesses never stand still. New competitors emerge, businesses grow, new opportunities emerge, and so on. Even if you know what you need when you launch your software project, that might be different than what you need when the software gets delivered. But sometimes the change is caused by the software itself. As individuals see what is possible to achieve with the new software, they get more ideas as to what they want the software to do.

Getting software right means small, frequent deliveries

To combat all these problems, successful software teams deliver their product in small, frequent deployments. As more of the software gets completed and delivered, the team and the business stakeholders both gain a better understanding of what the need is and the possibilities for solutions. Mistakes are caught and fixed early (when they are relatively inexpensive to fix).

What does all that have to do with how one pays for a project?

There are two reasons why this affects your method for paying for a project:

The biggest reason cited for choosing to pay a fixed fee for a new software project is to reduce your risk. However, your most important risk is not failing to meet an arbitrary time and budget, but that your software won't meet your needs. If your goal is to minimize your risk, minimize the risks that matter most to your business. For almost every business, a truly successful delivery requires a process that is adaptable to change. But fixed-fee projects, almost by definition, entail a fixed scope and so do not easily accommodate such flexibility.

The second reason for choosing to pay for new software via time and materials rather than a fixed bid is that nothing prioritizes what's most important like being forced to put a dollar amount to each request. In the initial stages of the project, when the delivery team and the business stakeholders are still getting to know each other and the project, it's impossible for any individual to be able to understand the true priorities. Business stakeholders almost always want everything they can think of. On fixed bid projects, trying to deliver everything can derail the whole project. Instead, being forced to pay for each feature individually keeps the business team focused and the project on track.

If you're still not convinced

On nearly all of the fixed-bid projects I've been on, the communications between the delivery team and the business stakeholders were dominated by arguments about whether particular requests were in scope or not. On time and materials projects, we focused on determining whether it was worth putting in new requests. In other words, the delivery team needed to keep control of scope to protect our financial interests on fixed-bid projects. On time-and-materials projects we merely focused on doing what was right. Which approach would you take? I know which I'd choose.

Does software craftsmanship make project success harder to attain?

Note: this post was originally published on InfoWorld.com.

There's a relatively new movement among software developers called software craftsmanship that focuses on improving the practices of software developers. On the surface, it seems like a good movement. After all, given the visible failures of software (the Affordable Care Act website failure and the Toyota accelerator issuescome to mind), it is easy to blame the developers. But it would be hard for me to depend on a software craftsmanship advocate to deliver a software project successfully. To see why, I'd like to tell you about my first career.

Life as a flute repairman

When I was getting my undergraduate degree in music, I kept hearing how there weren't enough band instrument repairmen around, and those that were there weren't very good. Since there weren't many jobs available to musicians, I chose to be an instrument repairman, focusing on being the best that I could be. I quickly discovered that most musical instruments were shoddily made, and that if I wanted to bring out the best in them I needed to do a lot of work to get them to play well. As I gained experience, I found ways to be more efficient (and therefore more profitable to the music store), but I used those efficiencies to look for ways to make better repairs, not ways to do more of them.

One day, I realized two things:

1. My focus on making great repairs succeeded. I think that my repair abilities would have compared favorably to nationally-respected individuals. But I wasn't profitable. I'd put $600 of repairs into an instrument that cost the store about half that. That isn't a sustainable business model.
2. Many of the repairs I did made the instruments incredibly responsive and easy to play, but those same repairs made the instruments less tolerant to misalignments. That's fantastic for a professional player who can tell the difference, but a questionable thing to do for beginning students who can't tell the difference between a problematic instrument and poor playing.

Try as I might, though, I could not bring myself to lower my standards so I could achieve greater profitability or make instruments more tolerant of misalignments. So I left the industry and became a Web developer.

What does that have to do with software development?

If I were to be completely honest, if I were to pick up a flute now, nearly 10 years after I left the music industry, I'd still be unwilling to find the appropriate cost/quality/maintainability balance appropriate for each situation. I'd still want to do the best job possible, making the same repairs on a $10,000 flute and a $600 one. But as a software developer, I am not tied to a self-defined set of criteria for high quality. Between quality, cost-of-creation, long-term maintainability, and time-to-market, there is no single correct balance for software projects. The balance I'd choose for a short-term marketing project is very different from the balance I'd choose for a mission-critical project for a nuclear power plant.

Where software craftsmanship comes in

When I look at the software craftsmanship movement from a high level, I see many good ideas. Like I was 15 years ago, they are focused on turning around the perceptions of a failing industry. But I can say from personal experience that such a singular focus can make it impossible to see the bigger picture. Just like I was unable to change my approach for the situation because it felt like I was lowering my standards, most software craftsmanship practitioners focus on what's "right," regardless of the actual circumstance. As a representative example, automated unit testing is definitely a good thing, but when taken to the level of full Test-Driven Development espoused by software craftsmen, you end up with a tangled, unmanageable mess. And I think it's no coincidence that a large number of people leading the "No Estimates" movement are also sympathetic to the software craftsmanship movement.

Software craftsmen and delivering projects successfully

It should come as no surprise that software developers who are most passionate about doing the best job they possibly can are often the best developers on a team. But if your best developer is a software craftsman, you must resist the temptation to put that person in charge of the development team as a whole for two reasons:

1. To deliver the project successfully, your team leader must understand when high quality is vital to success and when additional quality adds unnecessary costs and/or delays.
2. To get the most out of your software product, you need a software leader who understands the business need well enough to be able to anticipate problems and suggest solutions. Someone hyper-focused on their own part of the process typically isn't able to do this well.

Yes, this presents a management and leadership challenge by putting a seemingly inferior developer in charge of the development effort. But if you think about it, that would be the best approach for everyone. It gives the software craftsman the opportunity to focus on what he/she is clearly most passionate about but allows the team to direct that passion for the betterment of the project.

How just about everyone gets unit testing wrong

Note: this post was originally published on InfoWorld.com.

One of the biggest ways that people could leverage technologies more effectively is to use unit testing correctly. Most teams either don't utilize unit testing at all or use it far too much -- it's tough to find that "sweet spot" where the tests increase quality without hindering productivity. But if you're able to achieve that balance, you should be able to enjoy higher quality software with a lower cost of creation.

What is unit testing?

Before I go too much further, I feel like I should explain what "unit testing" actually is, because the term is misused quite frequently. Unit testing is the act of testing a small component, or unit, of your software application. Because the scope of each individual unit test is so limited, the only way to achieve it is to write code that tests your code, usually using a framework like NUnit or the Microsoft Testing Framework. A detailed description of how it works is out of the scope of today's post, but in a nutshell, unit testing is when a developer writes a test method that calls "real" code and lets him or her know when the actual results don't match the expected results.

Confusingly, many developers who are unfamiliar with these testing frameworks refer to the manual testing they do as "unit testing." That isn't "unit testing" -- that's just "testing".

Why in the world would I write code to test code?

To someone who isn't a software developer, the idea of writing code to test code may seem rather silly. But for those of us who actually do it, the benefits are easy to see:

1. During a typical test of a system, you have to log in and perform a specific set of actions in order to test particular functionality. This is incredibly inefficient and time consuming. Unit testing allows the developer to perform specific, targeted testing on the area in question.
2. When something does go wrong, the development team doesn't need to look in the entire system for the source of the bug. They can run all of the previously-created unit tests and narrow down their search.
3. Finally, as I mentioned last week, rewriting/refactoring code periodically is vitally important for the long-term health of your system. Rerunning all of the unit tests is a great way to help ensure that you didn't break anything in the rewrite.

When unit testing can be taken too far

Most of my experience with software developers is that they tend to think of things in terms of right or wrong. If it's right to write unit tests, then you must write unit tests for everything you do, right? Here are two unit testing beliefs that can cause your project more harm than good.

Test Driven Development (TDD)

The idea behind Test Driven Development is that you write your unit test before you write your product code. You then write product code to make the test pass. If you need to add or change the functionality, you change the tests first and continue making fixes until all of your tests pass. This is a nice idea, but a good chunk of the typical developer's code just doesn't need to be unit tested. Complex business logic absolutely needs to have corresponding unit tests. But writing unit tests for simple logic will require the developer to spend more time writing tests than delivering value to the business.

100% Code Coverage

One common metric that software teams track is code coverage, i.e. what percentage of the code written for the product is tested by a unit test. Many software development managers believe that 100% code coverage is necessary to ensure that the code is tested adequately. Code that is very highly tested is very tough to change. If unit tests are used excessively, software teams will find themselves considering the costs of changing the existing unit tests when changing the code, and these costs can spiral out of control.

So what is the right balance?

Unfortunately there are no hard-and-fast rules to know what unit tests should be written, but here are some guidelines that I follow.

Consider writing unit tests when:

• When the logic behind the method is complex enough that you feel you need to test extensively to verify that it works.
• When a particular code function breaks and it takes longer than a minute or so to fix it.
• Whenever it takes less time to write a unit test to verify that code works than to start up the system, log in, recreate your scenario, etc.

Consider avoiding unit tests when:

• When elaborate frameworks need to be created or installed (such as mock objects and dependency injection) just to get the tests to work.
• When the tests are applied to code that, if broken, has very little bearing whatsoever on the overall software quality.
• When the costs of maintaining the set of tests are higher than the costs of maintaining the actual product code.

To summarize, unit tests are intended to help development teams reduce costs by reducing testing time, reducing the need for regression tests, and making much-needed maintenance easier. Writing unit tests is absolutely the right thing to do if you want your software project to be a success. However, development teams that find themselves maintaining large libraries of tests are actually causing many of the problems that unit testing was meant to solve.

Making a business case for refactoring code

Note: this post was originally published on InfoWorld.com.

One common experience many companies have in the course of supporting software products is that the time and effort required to make customizations vary as the product ages. At first, customizations are easy because new features either mesh nicely with the existing code structure or they are completely new and can be easily added to the existing code. But as the product ages, changes affect other parts of the system, slowing down development and causing problems in seemingly unrelated parts of the product. The good news is that this isn’t an inevitable result of creating software. You can get around many of these problems by regularly refactoring code.

What is refactoring code?

Refactoring code is the act of changing existing code to be more understandable. Though it is possible to add functionality or fix bugs while refactoring, the act of refactoring code is a separate process from these activities.

Why in tarnation would you want to do that?

Think of writing code like writing a book. At first, a writer just needs to get his or her thoughts down. The book would probably be understandable after this first pass, but the reader would have to take more time to sort through the writer’s ideas. To help combat this, the writer will re-read, and in many cases, rewrite portions of the book. The idea is not to change the content of the book, but to make it more understandable to others. An editor will then read and change the book to further clarify the ideas it contains.

Many software products are shipped with code in the pre-edited state, in large part because the product’s users aren’t affected (at least not immediately) by the quality of the underlying code. This is usually a mistake, though, for the following reasons:

1. In most cases, other developers need to read the code to make fixes and improvements. This is significantly easier (therefore cheaper and faster) to accomplish if the code has been refactored/edited.
2. Debugging code is harder to do than writing code in the first place. Anything a developer can do to make the code easier to read in the future will save effort in the long run.

In short, code that has been refactored is easier to understand, therefore easier to extend and debug when enhancements are needed in the future.

But the business stakeholder wants their change put in now

There are times when it is appropriate to hold off on refactoring in order to put more features in. These times should be rare and temporary. In most cases, if you explain to each stakeholder what you are trying to do and why, focusing on why the delay benefits them (which again is that you’re building a foundation to help make the system more easily maintainable in the future, lowering time and cost in the long run), you’ll get agreement.

There have been times in my career when this hasn’t been enough to persuade the stakeholder; it was always in situations where the development team had consistently over-promised and under-delivered on software quality. In these cases, the development team needs to rebuild trust, and one way to do this is to communicate how refactoring will improve the reliability of the process and the quality of the product.

Many developers want to refactor everything. Should you let them?

Some developers, especially the better ones, tend to want to refactor everything. This isn’t always the appropriate course of action. If you remember the purpose of refactoring, which is to make code easier to maintain in the long run, it shouldn’t be hard to see why. Some code simply will never be touched again in its lifetime. Why spend the time polishing code that isn’t broken and will never be changed? With that said, though, I usually recommend refactoring code sooner rather than later, while the purpose of the code is still fresh in the developers’ minds.

How can you help prevent refactoring from breaking the software?

After the cost, the second most common concern I’ve encountered about refactoring code is the risk of introducing breaking changes to the software. No, end users generally are not understanding when something that worked is suddenly broken. Why risk making a change? Fortunately, automated unit testing is a fantastic way of mitigating this risk, but a further exploration of that concept will have to wait for my next post.

Why time and budget are stupid measurements of project success

Note: this post was originally published on InfoWorld.com.

Traditionally, software project success is measured primarily by two metrics:

1. Did we complete the project on time?
2. Did we complete the project within the budget?

If you think about it, though, these are somewhat useless success measurements. To illustrate why, I’d like to tell you about two projects that I completed while I was still in consulting. Names will be changed to protect the innocent.

The goal of Project A was to take a previously created prototype, which was built on top of a third-party software product, and turn it into a functioning system to allow the company to better manage its internal systems. The prototype was missing several key features, so the scope of the project was to add these features, then do a final run-through to make sure that nothing else was missing. We completed the project well ahead of schedule and roughly 25% under budget.

The goal of Project B was to create a website that could allow our client to consolidate several spreadsheets, Access databases, and paper documents into a single location for one of the company’s departments. We were to build the product so our client’s partners could log in and update the information themselves. We completed the project several months behind schedule and were almost 100% over budget.

Would it surprise you to know that I consider Project B to be the more successful project by a fairly wide margin? To see why, I’ll dig into what the respective businesses were actually trying to accomplish with these projects.

The high-level goal for project A was to implement a small project using the aforementioned third-party software as an evaluation to see whether it would be worth rolling out that software company-wide. The business need chosen was not a particularly good fit for this software, and the prototype was more built around the software than built with it. So as a demonstration of the software’s abilities, the project really was a failure even before I started writing code. To make matters worse, I had made a technical assumption that turned out to be incorrect, which led to some severe system performance problems. The company lost faith in the product, though our sales team persuaded them to move forward with the next phase anyway. They did, but kept tight control over the subsequent project, nearly derailing it in the process.

On the other hand, the long-term goal for project B was to consolidate several departments’ worth of spreadsheets and other disparate systems into a single software product for all of the departments to use. And while the initial phase of the software was significantly late and over-budget, it was generally understood that there was plenty of blame to go around, so we all took it as a learning experience and moved on. Because both our firm and the client improved our approaches, not only were we able to add two more departments to the product with relative ease, but we were able to do so significantly under budget, while continuing to make improvements for the first department. The overall product was a success because it met the most important business goals – increasing company capacity and increasing accuracy by reducing manual processes and disconnected systems. As a bonus, the company was able to glean insight they had no way of getting previously through the use of reports.

Then what are the metrics that software projects should use for success? They will vary project by project, but they should always be tied to desired business outcomes. For instance, a new eCommerce system should have revenue and profit goals, or a new workflow management system should have productivity goals. No, we shouldn’t ignore time and budget completely, since budget is a component of a profit goal, but budget is never looked at on its own. Yes, this means that many of these metrics will be influenced by multiple departments. In the case of the eCommerce site, meeting revenue goals would be partly the responsibility of the marketing department. But if your business is functioning well, that means that marketing and IT would have shared responsibility for the success of the software product, leading to increased collaboration and cooperation. Isn’t that a good thing?

Beyond requirements: understanding what the business needs

Note: this post was originally published on InfoWorld.com.

In my last blog post, I talked about how in some ways, the quality of software requirements can mean more to a project’s success than the skill of the programmers themselves. I also talked about how merely utilizing business analysts may actually make the problem worse. But what can we do about it?

Programmers need to know the product as a whole

Software projects that I’ve been involved in where the programmers had a thorough understanding of the business need to be addressed were significantly more likely to succeed than projects where the programmers were given a set of specifications to complete. Full stop. There is a belief among many business and technology leaders that a programmer’s time is best spent writing code, but so much of what a programmer actually does has little to do with code. Every day software developers must make decisions about when to spend the extra time to make a system flexible, where to spend time making the system extra secure, when to rethink design assumptions, where things may be simplified to realize cost savings, etc. Programmers who know what the software is trying to accomplish will make better decisions and will ask better questions. Programmers who don’t will not, inevitably leading to problems down the road.

Business leaders need to know what’s possible with technology

Unfortunately, many business leaders choose to “leave technology to the technology experts”. This is exactly the wrong approach to take if you want to have a successful software product. In nearly every one of the extremely successful projects I’ve seen, at least one business leader was actively curious about how and why we did what we did. The benefits were twofold:

1. Business leaders who have an understanding about what’s easy and what’s difficult to do with technology have better suggestions about how to accomplish their business goals at a low development cost
2. Business leaders who understand the compromises that occur during software development tend to be much more understanding when problems arise, leading to faster problem resolution

In general, the more overlap of knowledge that exists between the development team and the business leadership, the more complete the communication and the better the software product.

When possible, let business stakeholders customize and configure the system themselves

There are two primary ways I’ve had success getting business users involved in software projects. The first, especially useful when customizing a purchased system, is to give business users rights to customize the system themselves. The typical interaction here is to have IT take ownership of the implementation, partly because IT wants to feel relevant and partly because the business stakeholders don’t have time to get involved. But when the business stakeholders can get their hands dirty, so to speak, they have a greater sense of ownership over the project, leading to faster progress and letting the technologists focus on bigger-picture issues.

The other way I’ve had success with getting business users involved in software implementations (both purchased and custom software) is to give users (controlled) access to the data for their own reporting. Most reporting software is relatively easy to learn and use, so there really is no good reason to have software developers create simple reports.

If you hire an intermediary, hire a subject matter expert

In my last blog post, I had discussed how having a business analyst on a software project often makes requirement quality worse, not better. This is because business analysts that merely reword business requests in the form of business requirement documents unintentionally distort business goals. What about Subject Matter Experts (SMEs)? I admit I haven’t seen this work in person, but I could easily see a situation in which a true SME, adds value as a go-between for the development team and the business stakeholders.

Summary

I’d like to emphasize that there is no substitution for getting the software team and the business stakeholders working directly together. It improves communication, enables better decision-making (on both the developer and stakeholder sides), and leads to better overall satisfaction for all participants. Yes, I realize that this isn’t easy to do in many environments for a number of reasons. But do you want to let people stay comfortable, or do you want your software projects to succeed?

Low software quality? Poor requirements may be to blame

Note: this post was originally published on InfoWorld.com.

When I read articles about improving the quality of software, I read a lot about new programming techniques and languages, as well as new ways to manage projects and requirements. But there have been times in my career when I was asked, as a developer, to work on a project that was destined for failure before I had written a line of code. While projects this extreme have thankfully been rare, times when I had to rescue a project from bad initial expectations were more common - common enough that I decided to get an MBA to combat the problem (more on that in my next post).

Apparently it’s not my imagination. In his book "Software Estimation" (Microsoft Press, 2006), Steve McConnell discusses the top factors that might cause a software project estimate to be incorrect. For example, he compared whether the presence or absence of a mature process would affect estimates as much as, say, which software tools you use.

Based on the number of articles and blogs available, you’d think that programmer quality would be on top of the list, followed by which tools the developers used. Oddly enough, programmer capability came in third on the list, not first, beaten by both software complexity and requirement analyst capability. Software tools came in a distant 10th. Improving our software tools is not where we should be spending a significant portion of our time if we want to improve our software quality.

We are addressing the first problem through the adoption of agile techniques. Building software using agile techniques by itself doesn’t make software less complex than building software using waterfall methodologies, but it does limit the complexity the development team needs to worry about at any one time.

What about improving the requirement analyst capability? About the best improvement I’ve seen in this area is that our user stories are now in the format of: “As a <type of user> I want to <goal> because <reason>.” When you look at advancements in technologies, programming languages, and project management techniques over the years, the corresponding advancements in requirement gathering and communication are more than a bit underwhelming.

What about business analysts? Isn’t it their job to translate business requirements into something actionable by the development team? In theory, yes. But there are two reasons why adding more business analysts to the software development process is not the answer to improving requirement gathering.

The first is that business analysts must provide significant value to the software development process in order to provide more good than harm. Remember playing “telephone” as a child? You may have had a different name for it, but basically it’s the game where everyone lines up in a row and a phrase is whispered from one child to the next until everyone has heard the message. Then the messages are compared, and everyone laughs at how jumbled the message gets.

Communication within the business world is similar: The more people there are between the two endpoints (in this case, the business sponsors and the software developers), the more messages get garbled and priorities get colored by the intermediaries. Some BAs, usually subject matter experts, can add more to the process than they take away, but these BAs are the exception, not the rule.

The second, related reason not to invest in more BAs to solve the requirements problem is that nearly all of the best solutions that I have designed or built came about during brainstorming sessions between the business sponsors and the development team. When business stakeholders who have a thorough understanding of the business problem they’re trying to solve collaborate with software developers and architects with a thorough understanding of what’s possible, magic can happen. When you put people (or processes) in between the two groups most responsible for getting the project done you (at best) doom yourself to mediocrity.

What can we do to improve our ability to gather and document our requirements in a meaningful way? Nothing quick or easy, I’m afraid. But in next week’s post (and throughout the life of this blog) I’ll go over potential solutions

On hiatus

I have a new blog with InfoWorld! My contract with them allows me to re-post my entries here too, so I will not be abandoning this blog, but I do have to wait 15 days before I'm able to do so. That means that there will be a few weeks before I'm able to start posting here again. I plan to start posting here again before the month is over, but if you don't want to wait that long, you can check out my InfoWorld blog here: http://www.infoworld.com/blog/software-project-success/

4 common mistakes in rolling out purchased business software

If your job is to make software, and you're not living under a rock, you've probably heard dozens of stories of software projects that never made it to market because of uncontrolled scope creep, poor software quality, blown budgets, and the list goes on. In theory, purchased software should be safer, but I've witnessed more failures of rolling out purchased software than I have of custom software, despite the fact that I've been involved in roughly the same percentage of each type of project. What can go wrong? Here are four problems I have either witnessed or was brought in to fix.

Solving all problems at once

When companies first get their hands on new software, their instinct is to try to solve all of their problems at once. They'll jump head first into the new system but get lost in all of the possibilities of how to use it. After taking much longer to start than expected, they'll discover that their elaborate designs are invalid because of some basic understandings of how the system works. Instead, companies should focus on starting slow and simple, building on successes and learning from failures.

One time I saw this first hand was at a company that wished to use Team Foundation Server (TFS) from Microsoft as its project/work tracking software. In most companies, this would not be a big deal. This one, though, was going to try to customize TFS so that it could replace two custom-built work tracking software systems, custom-built time tracking software, and dozens of spreadsheets. When the company tried to tackle everything at once, they got overwhelmed with all of the problems that come with such an overhaul. After we reduced the scope for phase 1, the project started moving more quickly for the organization and allowed us to make continuous progress towards fixing all of the problems.

Choosing the wrong place to start

When companies purchase software to solve multiple problems, they typically jump in trying to solve the wrong problem. They'll either try to solve the business' most pressing need, or they use the software to fix an issue for a particularly assertive stakeholder. Even the best-designed software has a learning curve, and companies have to learn when it is appropriate to use the software and when another solution should be found. Instead, companies should focus on solving a non-trivial problem that the software is particularly well-suited to fix. This allows the company to build on positive experiences and provides a foundation to solve more difficult problems in the future.

Perhaps the most glaring example of this I've run across in my career dealt with a SharePoint implementation. My company was called in to help a client get started with SharePoint, since they had a great need for simplifying internal website creation and getting a handle on their document management. SharePoint is great at both of these things. But instead of starting on one of these projects, they tried to shoehorn a workflow system into SharePoint that stretched the abilities of the system. The implementation was so bad that the company almost abandoned the system entirely. 

Trying to customize the system too much

Purchased software can only do so much. In order to make the software appeal to as wide an audience as possible, the software makers will generally make the product as generic as possible. This means that businesses are faced with the choice of either customizing the system or living with a less-than-ideal solution. Most businesses will lean towards the former when they should really be focusing on the latter. Customizing third-party systems should be done as sparingly as possible, since any customization makes supporting the system more difficult in the long run.

This situation is actually quite common, especially with software whose main selling points are flexibility and configurability. You could pretty easily use the previous example as an example of why customizing the system too much is not a good thing. Instead, I will focus on some customizations I did as a consultant for a company trying to implement a Content Management System (CMS). Our client had products, but worked with distributors and so didn't want to post prices on their site, otherwise an e-Commerce system would have been appropriate. We had two choices - use the CMS as-is and ask our client to manually create pages for each product, or modify the CMS to make it easier to load and update multiple products at a time. We chose the latter approach. We did the best we could, but we never were able to get the system to work reliably, and the user interface was hard to use. We would have been much better off building an add-on that merely looked like it was a part of the system.

Not monitoring usage/progress

If you put new software in front of users, they will usually happily continue what they were doing before. They want to get their work done, and learning new software doesn't do that, at least not in the short term. If you make it impossible to carry on as before, they will try to use the new system, but in ways that you never would have expected. If either of these are allowed to continue, your new system won't be used very well if at all. Here the maxim "trust but verify" should be remembered if you want your new software to succeed.

An example I witnessed of this was a particularly difficult implementation of a Microsoft Dynamics CRM (Customer Relationship Management) solution. The project champion pushed for adoption of this system and customized several areas within CRM specifically for this company, but not only failed to follow up to ensure the users were using the system properly, but also neglected to train managers on how to use the system or why it is important to the company. When the project champion left the company, the software predictably fell into disuse to the point where no one understood why the company continued using it.

And you'll notice that documentation didn't make the list...

Many managers place a heavy emphasis on creating usable and complete documentation, yet I've never had a project succeed or fail because of the presence or absence of documentation. Motivated people will do the right thing regardless of documentation and unmotivated people won't check the documentation regardless of circumstances. Documentation is important, but it's a highly overrated component of software project success or failure.

Conclusion

If you want your software customization project to succeed, start by implementing a small and simple part of the system first whenever possible. Find a good fit for both your company and the software to help people understand how to work within the system. Have a roadmap for where you want to go, and communicate it clearly and consistently so people stay on track. Finally, monitor everyone so you stay on track to both ensure that people are using the system but also that the usage appropriately solves the problem at hand. If you don't do these things, your software either won't be used or won't be used well, so you won't get much out of your investment.

Unclear specs? Maybe you need to stop writing specs.

I read a blog post recently from a company describing how their product can help developers be more productive. I thought it was fairly interesting in that it talked about creating better specs and creating prototypes to help everyone understand the problem being solved. But it suffered from one fundamental flaw:

In the most successful software projects that I've ever worked on, we didn't write any specifications at all.

If you work in traditional software environments, the idea that you wouldn't have business analysts writing specifications for the developers is probably quite shocking. But skipping specifications works so well that I'd be hard pressed, as a developer, to work from a spec again. How did we make it work?

Generally, the software architects were responsible for all leadership roles on the software team. In addition to deciding how the system would be built on the software side, they were also responsible for making sure that the software met the needs of the business, communicating status to all interested parties, and ensuring that the software met established time and budget goals. Someone serving as the product owner oversaw the entire process, setting priorities and making decisions on behalf of the user team. What are the advantages of this approach?

Less staff needed

The typical process to create software specifications is as follows:

1. The product owner has an idea for a new change or feature and either writes up a summary or talks to a business analyst.
2. The business analyst spends time to understand the business specifications, and gets clarification from the product owner as needed. Then the business analyst writes business specifications describing the changes desired for the software system.
3. A senior developer or architect takes the business specifications and writes technical specifications describing in detail how the system should be changed to meet the business specifications.
4. The developers take the time to understand the technical specifications and clarify issues with the architect and business analyst. The BA will go back to the product owner as necessary. The developers then implement a solution.

If the BA is an expert in both the business processes and technology, and if the developers truly cannot understand the business need, this process makes sense. Unfortunately, in my experience neither of these is true. BAs are rarely experts in technology and developers can understand the business need. Yes, by severely reducing or eliminating the BAs from this process, you put additional work and responsibility onto both the product owner and the developers. But if you reach a common understanding of what you are trying to accomplish and are flexible with the details, then BAs and specs typically get in the way.

Less rework needed

If there is one constant in life, it's that things will change. Changes in software occur because of misunderstandings, changes in business context, changes in management, additional features needed, and so forth. Writing code to be easily changeable is more difficult than writing code to meet the need at the moment. Therefore, being able to anticipate where changes might occur is key to making software easy to maintain in the future. When the development team understands the business, then anticipating change becomes relatively easy. When developers are limited to implementing technical specifications, anticipating change can be almost impossible.

Unleash creativity

Some of the best solutions I've created resulted from conversations between me and the product owner when we were just tossing around ideas - me from the point of view of what's possible and the product owner from the point of view of what's needed. Specifications can gum up this creative process. Both product owners and business analysts will unnecessarily simplify their requests in a well-meaning but misguided attempt to put the developers in a position to succeed, resulting in a subpar product.

Less miscommunication

The single biggest problem in communication is the illusion that it has taken place.
-George Bernard Shaw

The idea behind specifications, both business and technical, is to ensure that all interested parties have the same understanding of what is supposed to be created. Surprisingly, detailed technical specifications are often inadequate for this task. My best guess is that people, when presented with a large number of small details, fail to see the big picture. This results in software that may meet expectations but doesn't meet the business or customer needs.

What about testing?

Many people, when reading this post, would wonder how testing is done, since the business specifications are often given to the testing team to create test plans. Testing is like programming in that it's much harder to work with vague instructions, but if you have the right people in place, vague instructions result in much higher quality. I have not worked with testers much of my career, but most of my experience with testing teams is that when they have specific testing plans, they only test using those test plans. But users act in unexpected ways. Testing teams that are given free rein to think like the users find much more than testing teams who follow a test plan. Here again it is better to ask teams to accomplish a goal than finish a series of tasks.

Conclusion

Software efforts are the most successful when:

1. The people who are building the software have direct access to the people using it and vice versa
2. Everyone has the same big picture understanding of the problems being solved with the new software
3. Effort spent on directly making the product better is maximized, while other activities are minimized

Writing specifications gets in the way of all three of these. If your developers are reasonably intelligent, then skipping writing formal specifications will improve your overall team productivity. If you have lower quality developers, or the product owners have little interest in being a part of the creation process, or you have a large team and need to keep everyone moving in the same direction, then specifications may be helpful. But don't create them just because by having them you are following best practices. In many situations, they are no longer needed.

Creating a leadership team to make your software project a success

In this, my last post in my Leadership vs. Management series (a week later than I intended due to the holidays), it's time to put it all together and talk about what leadership and management are needed for the successful completion of a project. This is going to be a difficult topic to tackle in a single blog post since the leadership team you'd put in place for a 200-hour project in a small company would look very different from a leadership team built for a company-wide mission-critical project for a Fortune 500 company. Nevertheless, I can still address some of the commonalities between the two.

Leadership

The leadership needed for a software project is relatively straightforward:

1. You need a Product Owner to serve as the final decision maker to ensure that the software meets business objectives, including functionality, timelines, and budget. He/she does this by keeping the team focused on the features and functionality that the software needs to accomplish its goals. He/she also must decide when a blown budget means that the project should be scrapped, when it should be scaled down, and when to forge ahead anyway.
2. You need a Chief Technical Architect to serve as the final arbiter between all technical groups (developers, server administrators, database architects, etc.). These groups have very different goals in their jobs and you need a leader who can balance the needs of the project as a whole, primarily (though not entirely) ensuring that the developers are able to deliver functionality without putting security holes or data issues into the system.

I've seen companies try to use multiple people for each of these leadership roles, but that approach almost always fails. When multiple people serve as the product owner, business objectives get ignored because an arbitrary budget isn't being met and important features get ignored in favor of ones pushed by more assertive sponsors. Having multiple architects almost always means having hours of discussion over security/stability vs. speed rather than delivering value.

I don't think it's necessary to have separate people serve as the business lead and the technical lead, but that requires one person to be an expert on the business as well as an expert in technology. Difficult, though not impossible.

For larger projects, it is possible to have leaders of smaller components of the software development effort, but they should always be answerable to the product owner and chief technical architect.

Management

While the leadership needed for a successful software project completion is relatively straightforward, the appropriate level of management is anything but. The number of managers needed will not only vary by project size and purpose, but also by company type, skill level of the workers, and the methodology used for project completion. However, here are a few guidelines:

• Waterfall projects generally need more management than Agile ones. It is quite possible, with the right approach and tools, for leaders to manage an Agile project without any help from a dedicated manager.
• Related to the first point, when time and budget are critical to your project's success, having a dedicated project manager can be extremely helpful.
• Be careful assuming that your leader can manage the project well (or vice versa). Management and leadership skills are quite different, so if you try to make your leaders manage the project, make sure they have the skills to do so beforehand.
• Nothing says "I don't trust you" like putting in excessive amounts of management. If you think you need a large number of managers for the number of employees you have, maybe you need new employees (or at least better training).

Summary

You need someone to lead the software project from a business point of view and you need someone to lead the technical effort. Committees don't work well here. Management should be kept to a minimum, though what this means for you will vary. On many small projects, you may not need any particular person to serve as a dedicated manager. On large projects, you may need several managers, each managing one portion of the delivery effort.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success