- Teachers and tech support have two very different perspectives on questions. Teachers say, “there is no stupid question.” Tech support asks, “why does everyone ask stupid questions?”
- The only things to fear are fear itself and bad code.
- Java was designed by software engineers who think programmers are better when their jobs are so structured there is no room for error. Unfortunately, the lack of room for success forces errors.
- Programming in Java is like trying to draw a picture using only straight lines.
- Agile development is the hippy approach to programming
- Upon experiencing deja vu while looking at code, it is time to refactor.
- Do not sit at the head of your bed late at night when you have gas if you intend to sleep on said bed.
- Some people just don’t get “while [1]; wget –delete-file $file; done”
- “Hierarchy is natural.” -Dr. James Robinson
- TVGuide.com does not consider the World Series of Poker to be a sport despite it being broadcast on ESPN.
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.