November 11, 2009

Business Requirements vs. Software Design

In the world of software development there seems to be two things that are always causing conflict. As a software developer I always want to do software projects "right." Most of the time this can mean significant time invested in infrastructure, design, architecture, and/or new code. As an executive I realize the value of getting things done as quickly as possible, but still with the right feature set.Both of these approaches can be valuable, and when balanced properly can lead to extremely valuable software.

On the software development side it always seems like it would be nice to have unlimited resources and unlimited time. If this were the case it seems like we could always come up with well designed, modular, maintainable software, that fills all of the needs of our customer. There would be time to do research, try out new technologies, and all of the other "cool" stuff that software developers like to do. Old code could be refactored to fit new requirements, new code would be well designed, fully unit tested and flexible enough to fit future needs.

On the business side all of these things are valuable, but there are many other things that come into play, like time to market opportunity costs, etc. Many times, the quicker you can get a product to market, the sooner you can see the response of customers and adjust/adapt accordingly. Taking another 4-6 months to get a product out may mean that a competitor is that much further ahead of you.

When these two ideas come together with the right mix, great things can happen. If developers are given enough time and resources to do a good job, then the software will have many of the same qualities as if the team had unlimited time. Of course the terms "enough time and resources" and "good job" are up for interpretation, and vary per project, but most teams should roughly know how much time they should spend for things to be good enough. Not perfect, just good enough. This means that people on the business side need to be understanding, yet apply appropriate pressure to make sure things are progressing.

When this all comes together teams can create great products. They won't be perfect, and they won't be quick, but they will fit the business need as well as possible and still not be just a jumbled mess of unmaintainable code. It can be hard to find the right balance, but it's worth striving for because it makes everyone happy: your customers, software developers and the people in charge. And you might even make a little money along the way.

No comments: