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.
Many of the greatest kings remembered in the history books or among the stories of the people are known as warrior scholars. They fought their battles, and when they had an opportunity to rest, they studied. Most focused on topics along the lines of politics, economics, and military strategy. However, there were also those with interests in religion, astrology, astronomy, and agriculture. A man with a talent for battle was a scary sight. A man with a talent for battle and a brain for making the battle easy was something to truly fear.
Lately, I have been associating with this image. I recently graduated college and took a short hiatus to get away from everything. It was a nice break including family, friends, Christmas, snowboarding, and videogames. Yesterday, I returned to the working world. I say return because after three internships and a couple student jobs, I do not feel like it is a wholly new experience. To me, going to work is stepping onto the battlefield. My coworkers are fellow soldiers, and the problems encountered in breaking greater service to the clients is the force opposing us. It is where I employ everything I have learned over the years. It is where all the training comes to the forefront.
Then I go home in the evening. Where medieval kings may have played chest by candle light, I dabble in web development and other programming projects. They are miniature versions of problems I may encounter at work. I begin to expose the forces at play and develop tactics to meet them. I spend time reading books and blogs. I watch enlightening shows on the television. You may think all I do is watch sports, but I argue that football relates to far more of life than the local three-day forecast.
Tonight’s agenda is no different. Tonight, I resume reading The Art of War.