I recently read this article on the need for non-software companies to recognize the impact of their internal software development. It reminded me a lot of where I work. The general culture at my workplace says, “We are in the x business. We don’t do software.” The idea being we buy software at every opportunity and only resort to developing it when we have no other options. The result is a lot of money thrown at very expensive software packages which hardly do what we want after we fight with for a year. There has been a recent move towards using open source software over in-house software, but it still suffers from the same problem. The result is we do not apply as much emphasis on developing our software development environment as we should. Afterall, why bother modernizing if you only write a handful of apps never intended to see the light of day?
The refusal to address our software problems is only making matters worse. While commercial products often do meet our basic infrastructure needs, they do not and cannot come close to making us a successful business. The result is we implement the software closest to the core of our brand in-house. As time goes on, we continue to build applications on top of past applications. However, many of our past applications are outdated or were quite possibly outdated the day they were created. We continue to incur debt. Quite frankly, we are falling behind. Old applications need renovated. Current applications need modified. New applications need developed. All the while, we use yesterday’s practices because we do not have extra time to learn modern techniques.
Nearly every business today does software. Particularly if a business provides online services or makes transactions, it needs to consider itself in the software industry. Take a look at a company’s income and see how it aligns with spending on development resources. If a large percentage of revenue comes from areas supported by in-house developers, this is a good suggestion the company is in the software business. They need to put effort into improving and supporting their development efforts because otherwise their software debt will consume company expenses.
I have spent the past six months trying to learn to balance today with tomorrow from an IT perspective. Today is about providing solutions to problems one has today. Tomorrow is about solving problems one will have in the future given their current situation and direction. The purpose of IT is to support business. While IT for IT’s sake is fun, it does not provide real value. Aligning IT to solve business problems is key to success. When business has an idea for a great new product, they need a solution to implement the product. By spending large amounts of time implementing the perfect solution which is robust, but easily adaptable to any direction the product may go, the business may miss out on its opportunity to capitalize on the full potential of the product. However, implementing the quickest solution to get to market as fast as possible can leave the product unable to adapt as customers begin to request new features. Balancing these two sides is key to the success of IT.
My company is very oriented towards today. They want a solution as soon as possible. Cleaning up the aftermath is left for tomorrow. The problem is tomorrow quickly becomes today and new problems need solutions implemented. Too often, no time is left to prepare for tomorrow. Frequently, we find ourselves wasting time today because all we thought about yesterday was yesterday’s problem. One example is the vast quantity of processes we have today with their own implementation to FTP files. FTPing a file is a fairly simple process and easy to implement. As a result, any time we needed to FTP file, we implemented it for our specific situation. As a result, we have never created a generalized process for FTPing files. Implementing a new specific solution always seemed easier than trying to make something more general and reusable. However, when looking back, we would have been better off creating a generic process to FTP files and reusing it as necessary than implementing one for each specific situation.
As a counter to my company’s constant band-aid on top of a band-aid approach, I repeatedly voice a need for general solutions which can be reused. However, it is not uncommon for me to find myself in a situation where there simply is not enough time to develop a generic application over a specialized application. Sometimes, we simply do not understand the domain well enough to generalize. If we tried, we would likely spend a lot of time creating a process that really is not reusable. As a result, we would need to spend more time reworking it later.
The result is we need a mixture of today and tomorrow. When time is of the essence, we need to create a solution that meets the requirements. That being said, we also want the application to be designed to be easily changed down the road. Then, as additional requirements develop, we modify the original application to meet the expanded scenarios. The result is something akin to agile software development practices. The key is to allow time to refactor the original application. If the requirements are moderately different early on, it may be more work to adopt a common approach. However, as the area matures, the small time spent upfront will begin to be returned. Fortunately, the time spent at the beginning of the process is not too great to warrant a large risk of wasted time if the product flounders. In essence, we need to meet today’s problems by adapting yesterday’s solutions to be prepared for tomorrow.
When it comes to information technology, big companies are slow. The cause of this is all the structure added to prevent someone from breaking the entire system. It is a ton of overhead plain and simple. Remember when people used to write code, compile it, run it for five minutes, and call it a new version? When developing for a large company, the maintenance cycle is a little different. A user finds a bug and calls tech support. Support confirms the bug and reports it. A resource manager assigns a priority to it and puts it in a queue for a developer. The developer gets to it after finishing all the other tasks in front of it. He fixes it and performs some very basic testing. Then the QA resource gets their hands on it for regression testing. Finally, the new code is pushed out in the next deployment. Then another user finds a new bug and the process repeats.
There is a benefit to all of this overhead. It becomes very difficult for an individual to accidentally break something. There is a cost to all of this overhead. It becomes very difficult for an individual to intentionally fix something. When does the need to create something new override the need to prevent something being destroyed? I believe those of you who have written code in both Java and a scripting language such as PHP or Ruby understand what I am talking about. There is something to be said for preventing stupid mistakes. It also happens to be true that when challenged, someone will step up to the plate and still manage to find a way to break things. At what point do we assume people are smart enough not to let stupid mistakes get into production so they can focus on enhancing a product rather than processing red tape?
When it comes to application security, no one can ever guarantee their application is one hundred percent secure. They can only mitigate the risk in the most effective means possible. In the security industry, cost and usability are the primary factors. A similar parallel needs to be considered in software development lifecycles. No one can ever guarantee their application does not have a bug. They can only mitigate the risk in the most effective means possible. The primary factors here seem to be cost and maintainability. On one extreme, we could allow code to never be changed. The good news is everything that works would continue to work. This is under the assumption the world around it is not changing. The bad news is everything that does not work will never work.
With a big company that has a lot invested in their current processes, they want to be sure a change is going to be worth it in the end. There will have to be manpower invested to convert current processes. Resources will have to be pulled away from the current system to research new possibilities. Big companies are big because people have come to rely on them. They do not want things to break because they do not want to break the trust their clients have in them. However, if they do not evolve, a smaller, more agile company will replace them. Because of this, such companies must continue to press forward. Keen discretion must be used to pick the right opportunities for moving forward.
Ultimately, it seems all sizes of companies are needed. Small companies to drive the industry forward. Big companies to keep the industry afloat. The companies which will excel are those which can balance these forces within themselves. By breaking organization down, the fluidity of a company can be increased, but it comes at the cost of efficiency. Efforts will undoubtedly be duplicated without proper management and oversight. Learning to share resources, and yet, at the same time, be independent will be key.