Many of the processes that seem to exist or that I think about and draw as state diagrams in teleconference meetings are because the current software solution is only partially implemented or buggy and untested; but, the untested gripe I have is a much longer post for a different day. Instead of investigating the root cause and fixing that, when I ask about issues that affect the website I routinely hear things like “We do not have the resources”, “the code is to complex and this would require a major refactoring of the application code - we don’t have time/resources to do that.” A recent example of that is, “That machine didn’t have an account that my script could use, so I had to hard code my password.” Then the password changed every 90days and the script broke, for over a year! So every 90 days someone had to notice that the output of the script was not being updated anymore and ask IT why. If the single point of This make me wonder, when an issue was first identified how much money it would have cost the company to give the identifier the leeway to identify the root cause and pursue a robust and testable solution vs. how much money it took to implement a process and and train people on the workaround or the lost productivity time when the process/script broke, the script author was not available and temporary workarounds had to be investigated and implemented. There is a double edged sword to everything and that included working in a large business or a start-up. Having dipped my toes into both worlds I think that they could both learn a lot from experiencing live in the others world.
9/3/2010 ~ 2 min read
