I grew up to the phrase, “Never say never.” I grew up reading fantasy and science fiction books and watching action movies like any other boy. However, perhaps more than the excitement, I loved the story. When I got to school, I did not stop reading or watching movies. I also began getting into role-playing games (RPG’s) on both the console and the pen-and-paper variety, think Dungeons & Dragons. While those are a little beyond the norm, I took it a step further. I paid attention in history class. I heard about Alexander the Great and Julius Caesar. I read about Napoleon and General Eisenhower. I watched documentaries on Ulysses S. Grant and Robert E. Lee. I grew up believing a person could be great. I believed I could be one of them. Then I got older.
I was expected to find a way in life. I could not continue dreaming of being the next Michael Jordan, Steve Young, or Andy Roddick. I had to grow up. I was never very keen on the idea. By this time, computers had become an avenue to more stories and dreams. I began to pursue basic web development, and then on to programming. I could not decide whether I wanted to make games that future generations could love or websites which would open the eyes of others. I began walking down that path. On the side, I kept myself grounded with history classes. They were a constant reminder of where I wanted to be. I wanted to be in the history books.
I graduated college and got a job. I got told, “Welcome to the Real World.” It turns out it is not much different than whatever world I was in before. People have expectations, and it is my responsibility to meet them. That means even if I do not like it. I am very independent. I do not like someone else telling me what to do. At the same time, I want people to listen to me. I used to yell louder in hopes I could drown out the others until they had to listen to me. Sometimes I still do. With my job, I wanted to write code. I wanted my code to change the world.
My boss recently shifted me into a new sort of role. I coordinate developers literally on the other side of the world as we work on an application used by people in the same city as me. The new role requires getting up before the sun because people on the other side of the world work very different times than we do here. I am told it has something to do with an 11.5 hour timezone difference. I also spend most of my days in meetings. Some days I spend the entire day in meetings. Each meeting has people asking me to get work done. I struggled to understand how I was suppose to get work done while I was constantly in meetings. I wanted to be writing the code rather than sending it off to others. I could do it better. I yelled a little bit.
I still do not know whether I want to continue pursuing the road I am on or return to the fork in the road. However, in traveling down this new road, I learned something. If I want to be great, I do not have to do the things at which I am great. I just need to continue meeting the challenges laid before me. I have to rely on the people around me to help me. I have to rely on others to point me in the right direction when I can no longer see the road. I will have to try new things. I do not know where I am going. I do not know where I will end up. The one thing I know is I can never stop trying.
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.