A few weeks ago we talked about, single points of failure. We talked about power lines and data lines having more than one place of ingress to the building. We spoke of multiple power sources, as well as multiple data paths; much like the internet has multiple data paths. See that post for more information about hardware single points of failure.
Today the subject closely relates to this but it is “software.”
Some companies use off-the-shelf solutions and some decide to “roll their own.”
Today we are going to look at the pros and cons of this practice.
Off the shelf:
PRO—
Ready to go with a company to back you up.
A “normal” IT guy or gal can install it and most probably support it as most of these types of software companies have classes on their software. They offer such classes because they want their product to be successful and they most probably offer some sort of certification for it as IT folk seems to be “gaga” over certifications!
If there is a problem there is a support path.
Depending upon the complexity of the software there may be add-on-modules for your particular needs. That translates to a cost savings of only buying what you need.
IT personnel are much less expensive than in house programmers and unlike in house software, there is an end to the expense.
Canned software is also easier to find IT people who can work with it vs some home grown software that no one has ever seen before.
Hiring your own in house programmers is like hiring a carpenter to do some project for you that charges by the hour and the project that you want him to do is ill defined.
There was a show not too many years ago called Murphy Brown who had Eldon the painter in her house. Eldon was always doing something and was in her house for the entire show doing something. While Eldon was a bit player and supposed to be there for this part, the analogy is that she left everything up to him and he had a job for life.
You don’t want an Eldon working for you, unless you really like his company.
With off the shelf or canned software you work within its limitations.
Scope Creep:
Having managed programmers in the past and reporting their progress to the president and or board, it never ceased to amaze me that someone would ask the question, what would it take to make the software do X.
The way that this works is the decision makers come up with a defined set of expectations, which allow a budget to be created. Once that process is done, so is the definition of the project. It is then up to the manager to manage the project and make sure that certain milestones are met and in budget.
The danger of developing things in house is that inevitably someone modifies the definition after the budget has been blessed. If you have no “extra” built in for unforeseen events, than you have to go back to the board and beg.
You can explain it is because they wanted something else but you still come off looking bad. You should have foreseen that they were going to ask for that and put it into the budget. (There is a little truth to that last statement.)
With canned software, the project is much more manageable as the cost is pretty much set in stone. Support contracts are easily budgeted for as is training of your people.
Designing in house software has more risk than payback.
Most probably you keep your staff small so if one person does this part of the project and another that part of the project and then something happens to them, well, you have a single point of failure.
Documentation of the software developed in house must be meticulously managed and like a DR plan, it must be tested! If it is not done in this manner the software becomes worthless when that developer is no longer there.
Around 10% of development time is or should be documentation time. Documentation should contain a version number much like the rev level of the software. Outdated documentation is worthless.
Unlike the mindset among some IT people that do not document anything, the programmer must document their software in such a way that a future programmer can pick it up and run with it. This documentation might include things like UML diagrams and key design features. Comments in the code are nice, but are not enough.
As with any DR, there is a “living document” as it also is with code. The documentation is a live process and must be updated as the code is developed.
Programmers certainly know the best practice techniques of this process but the CEO may not. Some people develop self documenting code.
The old adage “Don’t expect what you don’t inspect.” Is salient, germane and just damned important!
There are no good surprises in business and if you keep with that as your mantra, you will be served well.
The Cons to off the shelf are that it is fixed. Whatever you purchased is only as flexible as it was designed to be, “a one size fits all” solution. For most companies this may be enough.
Most companies are generic enough that they can work with that.
Some projects are just foolish to try and roll your own as the cost will not justify the ends.
I know of one company who has someone in the upper echelon of the company that is a developer. Instead of using canned software for such things as DNS, they wrote some scripts with pointers to a LMhost file. Of course there was no documentation so as an engineer figuring out why there were duplicate IP addresses or why IP addresses did not match the device and so forth was a nightmare! Wireshark to the rescue.
There are standards in the industry for a reason.
Canned software allows the CEO to get the best talent for the job and allows him a wider field to choose from. If their set up is so unique that only a select few can manage it, he is paying way more for a system that dies when the creator of it dies or just gets upset and quits. The golden handcuffs are than on the business owner as he must necessary play nice with his programmers.
Remember, no employee should be sacrosanct. Everyone must necessarily be treated as expendable because of the “hit by a bus scenario.”
In house code must be tested to make certain that it is supportable by outside people. If it is not, it should be fixed, scrapped or replaced with something that is, or is off the shelf.
This is a very important reason to have a “good CIO!” Any good CIO has the companies’ best interests at heart and knows better to save a penny here and waste thousands there. The CIO must be incredibly technology savvy as well as possess business acumen.
I have worked for many over the years that were one or the other or neither, but they did go to school with the president so they were buds.
Failure to plan is planning to fail!
Hire a CIO that knows his or her stuff.
If you are uncertain, hire a DR consultant to come do an audit.
The consultant, if met with truculence on the part of the IT staff, would be a good indicator that your staff know that they have bones buried.
Plan to look carefully at your software needs and if you decide to develop in-house, make sure that your CIO knows what his or her programmers are doing.
Programmers make lousy CIO’s, just like a surgeon makes a lousy GP.
If you have a belly ache and go to a surgeon for advice, what do they do? They cut flesh. Their first thought is to open you up and see why you hurt!
You go to a GP who takes your history and discovers that you had sushi some time back, has you checked for the helicobacter virus; a few antibiotics later you are fine and you don’t have some scar on your belly, not to mention a long recovery time.
Bad decisions in business cost money and bad decisions with your health also cost money and could cost you your life.
Programmers not only make bad CIO’s, they make bad managers. Most programmers are very myopic. They have to be to code. When you take someone with that skill set and throw them into management, they do not have the breadth of experience necessary to handle a wide variety of issues. I have seen too many over my career that started out as programmers and made convoluted programmatic solutions for an easy fix situation.
There was an old cartoon many years ago where there were two computers in a room. The Secretary and the exec, both on their computer. The IT guy played as Goofy, or a Goofy look-a-like was asked to find a way to get the file on a diskette from this computer to that one. Goofy takes the disk, scratches his head for a second and then like a Frisbee, tossed the disk to the secretary. K.I.S.S.
The CIO must know enough about all things IT, to know when smoke is being blown up his or her southern most orifice. The CIO must also have enough business savvy to be able to negotiate with the CFO who has a different skill set, as well as deal the CEO and those on the board of directors.
What you don’t want is some sycophant working for you and you don’t want a control freak either. The CIO must be very well rounded with lots of experience.
Management must not become your single point of failure.
-Best
Copyright 2014 Timedok All Rights Reserved
TheTimeDok 