Keeping Software Simple Part 1 Introduction Installation

Keeping Software Simple Part 1 Introduction Installation



Keeping Software Simple - Part 1 - Introduction / Installation
Install,​ Configure,​ Test,​ Use,​ Tune,​ Maintain
We get so mired in​ the​ details we tend to​ forget the​ big picture .​
software that has moved from the​ development phase to​ either alpha,​ beta,​ or​ general availability involves six things.
1 .​
Install
2 .​
Configure
3 .​
Test
4 .​
Use
5 .​
Tune
6 .​
Maintain
These items will certainly require iteration .​
For instance,​ we typically do not know how to​ tune something optimally until we begin using it​ in​ its intended environment .​
Then once we tune it​ for a​ particular environment we use it​ some more .​
And of​ course tuning usually requires going back and tweaking the​ configuration,​ which in​ turn requires us to​ re-test.
We certainly need to​ drill down on​ each of​ these entities and provide more detail,​ but before doing so we need to​ come to​ consenus that these are the​ actions items involved in​ any piece of​ software.
Without getting too wrapped up for the​ moment in​ the​ how let us try to​ answer the​ following questions.
First up: Installing Software
QUESTION
Is there any software out there that you​ know of​ that does not need to​ be installed? Somehow it​ just magically appears and we can begin using it​ :-) .​
Of course not.
MISSION STATEMENT
With the​ exception of​ configuration,​ we cannot test,​ use,​ tune,​ or​ maintain software until we have figured out how to​ install it .​
So might it​ be a​ good idea to​ put together a​ procedure for installing the​ software?
SOME NORMS
* We should always strive to​ install software in​ a​ manner that can be fully automated .​
No,​ I​ did not fall off the​ turnip truck and realize that this is​ not achievable for all software .​
But,​ if​ this is​ not doable you​ better have some compelling (in writing) reasons why not.
* If we cannot install software via a​ fully automated process then we should achieve to​ install software in​ manner that we could train a​ chimp to​ do .​
In other words the​ procedure should be so easy to​ understand that anyone could pick it​ up and accomplish it .​
Of course if​ we can achieve this then we are pretty much back to​ the​ first bullet.
* Staffing a​ configuration management team costs money and resources .​
The more complex the​ software the​ more of​ this you​ need .​
The more complex and/or convoluted your software development methodology is​ the​ more of​ these people you​ need .​
Frankly,​ a​ good software development methodology should seeks to​ minimize this function .​
Sorry,​ I​ have nothing against configuration management .​
It certainly is​ a​ needed and vitial function .​
My point is​ that it​ largely exists to​ deal with the​ crap and kludge,​ and general mess the​ development staff has lobbed over the​ fence.
* If your configuration management team is​ unable to​ move and manage files,​ directories,​ and do builds through an​ automated manner that can be accomplished by toolsets then it​ is​ likely that you​ have 1) hired a​ bunch of​ doofs to​ serve this role,​ or​ 2) are having some degree of​ crap being lobbed over the​ fence by your development staff .​
If you​ do not like these two choices you​ had better be prepared to​ defend in​ writing,​ in​ detail just what the​ problem is​ .​
The goal is​ reduce variance .​
By reducing variance we reduce installation complexity .​
As a​ trivial but common example to​ this point I​ work with a​ product that in​ each of​ last five releases the​ development staff have relocated the​ same set of​ files that make up our runtime application api .​
They have had absolutely no compelling reason for doing this .​
Does this causes our configuration management group to​ have to​ redo tool and redo deployment procedures and processes .​
I​ am not advocating that there is​ never a​ reason to​ do something like this,​ I​ am merely stating that if​ you​ do you​ need to​ have 1) a​ compelling and bone-fide written reason for doing this (as in​ an​ engineering order,​ or​ new design requirement); and 2) you​ had better articulate this up front so everyone can prepare for the​ impact this change is​ going to​ have downstream for everyone that will be accepting these changes.
* For software installation that requires configuration during the​ installation process itself you​ will need to​ ensure that your procedure contains a​ pre installation requirements section .​
For example,​ oftentimes one is​ required to​ create a​ default directory,​ or​ set a​ default location,​ enter a​ url,​ select a​ communcation protocol,​ have a​ password and login,​ a​ license key etc,​ etc.. .​
.​
Make sure the​ person doing the​ install has all of​ this information before they begin .​
Seldom have I​ seen where an​ installation does not actually requires a​ decision point (a fork in​ the​ road) .​
Generally you​ can provide the​ answers to​ these forks in​ the​ road up front .​
For example,​ installing SQL server askes you​ to​ select a​ communication protocol .​
This is​ a​ decision point that should be known up front and provided to​ the​ installer.
* Installing software on​ different operating systems or​ different version of​ an​ operating system can be quite variant .​
As a​ general rule of​ thumb if​ the​ variance is​ more that 10% (collectively,​ no more than!!!) create a​ separate procedure.




You Might Also Like:




No comments:

Powered by Blogger.