Let's Talk Dev

It is imperative that a development team recognize technical limitations. It is equally imperative that a business work with the development group to build functional requirements which recognize these limitations.

Conversations about technical limitations need to happen early. Take the time to dig deep into the real limiting factors. Look at what changes can be made to business requirements to greatly simplify the system. This will help with scalability and maintainability. It will also lower the initial development cost and time. Often these changes can be made without significant impact to the usability and value of the product. By recognizing technical limitations early, time and money is saved now and into the future.

Time and time again I see systems that have been built around functional requirements requiring a far more complex system than necessary if technical limitations were recognized early.  An example of this is an application I have been working on for the past several years. It was built with the ability to edit any number of records on multiple pages of a search result set before saving the changes. Doing this made scaling difficult and costly. It also increased the complexity of the system to the point where maintaining and extending the system was slow and costly.

After a few years of supporting this model our development team finally asked how necessary this really was. After a little thought and discussion we realized that this ability was not actually useful.

If this conversation had taken place a few years ago we would have saved many thousands of dollars and had happier customers with a better performing system.

Recognize technical limitations early by putting in reasonable limitations and your products will be more profitable.

Business people focus on business requirements. When they consider requirements they will be thinking from the client’s viewpoint. The focus will be on what features will be required. They will be paying attention to what business processes are being addressed.

Sometimes items that hint of a technical requirement may work their way in like a service level agreement (SLA). Any of the technical requirements might get addressed in the business requirement but more than likely they will not.

If you don’t step in as a development manager and make sure that the technical requirements are flushed out it won’t happen. You have to make it happen.

 If the developers jump right into building the system key technical needs will be overlooked.

The best developers and architects will try to build most of what will wind up in the technical requirement into the system without it being specified. Most developers will find themselves pushed into a corner with deadlines and these technical considerations will go by the wayside. If we have clear technical requirements for the system this can be avoided.

In order to make sure we get a good system with all of the technical considerations being addressed we need to create a technical requirement as well as a business requirement.

Regardless of your development methodology you are using this holds true. It is just as true for Agile SCRUM as it is for Waterfall. Any functionality being added to a software system should take into account the technical requirements as well as the business requirements. It can be done on the system level or the individual functional level. It just has to happen.

It is the responsibility of a development manager to make sure that these technical requirements are flushed out and included. It may involve architects, team members, or other resources to help define these technical requirements but the buck stops with the development manager.  You would never let your team try to build a system without a business requirement; likewise you should not let them build a system without a technical requirement.

What type of things should be in the technical requirement?

A lot of what goes into the technical requirement should be decided in conjunction with architecture and support. Usually these requirements would reflect a standard for the entire product suite. There is no end to what you might consider but here are some items I recommend considering for your technical requirement:

• Instrumentation - One of the key features that will go into the technical requirement are the instrumentation needs of the application. The needs will vary from application to application and even within features of an application.
• Multi-Language Support - Though the business might not be planning a multi-language version of the application consideration should be given to the ability of the system to be expanded to include other languages.
• Themes/Skins - Any application will want to undergo change from release to release. The need for adaptability should be considered. Allowing for themes/skins in your applications will allow you to adjust to changes in marketing and make it very easy to give the application a visual facelift as you release newer versions. The need to do this from the client point of view would be a business requirement but the ability to handle should be considered a technical requirement.
• Scalability - How scalable does the application need to be. I would suggest that all applications should be highly scalable. My view is that if I get hit with an unexpectedly large number of new clients from sales I’d like the option of just buying some more hardware to keep the system up and running. The needs of individual applications will vary but this should be considered.
• Ping - What will it take to ping your application and verify everything is up and running? Single install applications don’t often need this but enterprise systems will need this always. You are going to want to consider how you will verify that everything is up and running and if there is a technical requirement that needs some implementation to make this work well.
• Warnings/Issue Reporting - Does the system have a need to send out warnings when certain things happen? Perhaps this can be covered in what you are planning for instrumentation, perhaps not. I definitely want to know when there are issues happening in my production environment.
• Client Support - Does your application support only a web based client or maybe other clients like a windows forms client or even an iPhone or Google Apps client? Consider the fact that you may need to support other clients in the future. How much support for this does your application really need?

Add to the list as you need and make sure that any technical concerns raised by support reps, database engineers, automation engineers, test engineers, developers and architects are all addressed.

It looks like a lot of overhead but the results will be much better for the effort.