5 mistakes from Linux IT Managers

Five common mistakes that Linux IT managers make and tips to avoid the mistakes.

Mistake #1: Reactive, not proactive

• have disaster plans in place rather than trying to implement a disaster plan on the fly (hardware failure, natural disaster, compromised systems,...)

• plans for the future in terms of capacity planning, upgrades, and support.

Mistake #2: Failing to emphasize documentation and training

• Document, in an easy-to-find location, organization-specific information, such as passwords for servers and services, installation instructions, guidelines, firewall rules, etc..., anything that's not obvious, standard, or found in existing documentation

• Set up a central repository for documentation and policies, and make documentation a job requirement for systems administrators and programmers.

Mistake #3: Failing to assess strengths and weaknesses

• know the strengths and weaknesses of their teams.

• Instead of doing everything yourself, consider outsourcing to a contractor (ie. website hosting, samba introduction, ...)

Mistake #4: Too much, too quickly

• move cautiously when replacing existing systems.

• Don't replace working systems with new systems that have reduced functionality just to replace proprietary software with open source.

• do test deployments and have extensive discussions with users about what they need before rolling out any replacements.

Mistake #5: Security as a secondary priority

• provide a comprehensive security policy for your organization

• from the front door to the firewall, security must be a pervasive element in an organization's IT architecture.

• don't be shy about calling in a consultant to provide assistance in securing your organization's IT infrastructure.

Read the complete article at IT Manager's Journal

Have you experienced other major mistakes by Linux IT managers ?

Bug Priority and Severity

Differentiate Priority and Severity. The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time.

Therefore:

Track priority and severity separately, then triage appropriately. It helps to have input from others on the team on priority. The importance of a bug is a project decision, different from the bug's perception by the Customer. In some cases it makes sense to track Urgency, the customer's point of view, separately.

Microsoft uses a four-point scale to describe severity of bugs. Severity 1 is a crash or anything that loses persistent data , i.e., messing up your files on disk. Sev 2 is a feature that doesn't work. Sev 3 is an aspect of a feature that doesn't work. Sev 4 is for purely cosmetic problems, misspellings in dialogs, redraw issues, etc. This system works very well. (Interestingly, sev 4 bugs end up getting set to priority 1 fairly often, because they are frequently very annoying to users, and fixing them is generally easy and doesn't destabilize things.)

Keep clear the difference between severity and priority". The example given says "a start-up splash screen with your company logo backwards and the name misspelled is purely a cosmetic problem. However, most companies would treat it as a high-priority bug."

Read more at c2.com: Differentiate Priority And Severity

Law of Demeter (LoD), Low Coupling

One of the bigger challenges in software engineering is keeping the complexity of the design under control. Two major techniques to reduce complexity are reducing coupling and increasing the cohesion of the software components/objects/methods.

The Law of Demeter is a style rule for designing object-oriented systems. "Only talk to your immediate friends". The rule was discovered at Northeastern University in 1987 by Ian Holland.

A more general formulation of the Law of Demeter is: Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Or: Each unit should only talk to its friends; Don't talk to strangers.

The LoD is a more specific case of the Low Coupling Principle well-known in software engineering. The Low Coupling Principle is very general. The benefit of the Law of Demeter is that it makes the notion of unnecessary coupling very explicit.

The main motivation for the Law of Demeter is to control information overload; we can only keep a limited set of items in short-term memory and it is easier to keep them in memory if they are closely related.

Rumbaugh summarizes the Law of Demeter as: A method should have limited knowledge of an object model. This view leads to aspect-oriented programming: we pull out the method and transitively all its auxiliary methods into a separate aspect. This works best if the separate aspect has limited knowledge about the object model.

Read more on the Northeastern University page on the Law of Demeter

SOA, 4 Steps, 7 Principles

Service Oriented Architecture (SOA) promises a number of benefits of which two stand out:

• reduced cost through reuse
• increased flexibility to adapt applications in order to meet changing business requirements
  

Put simply, SOA is an architecture that enables the integration of multiple software services, creating applications and business processes that span multiple technologies and business units.

The four steps involved in delivering an SOA:
1. Expose functionality as services: enable existing functionality to present usable interfaces and message formats to the rest of the business
2. Manage the orchestration of these services, the sequence in which they are invoked
3. Manage the mediation between diverse datamodels and service definitions
4. Integrate with existing IT infrastructure

The seven principles to help you choosing the most appropriate approach:
1. Minimize costs of disruption, costs replacing or adapting existing technologies to create an SOA solution. Focus on supporting the most complex integration tasks, rather than rebuilding the entire IT stack.
2. Integrate incrementally. Deliver on a gradual, needs driven basis, targeting specific, tactical challenges, whilst keeping a strategic eye on the end goal. Look for product that are easy to learn, productive, small footprint but scalable, distributed.
3. Reduce coding. Many products enable orchestration to be configured rather than coded. Unfortunately the same is rarely true for mediation.
4. Use industry standards wherever possible. Standards are proven technology reducing the risks, they enable diverse implementations to fit together, and they help avoid vendor lockin. Use widespread adopted standards like JMS, XML, BPEL etc.
5. Accept the things you cannot change. Many of the systems and applications use old data formats (csv, excel, cobol data formats, ...). These systems can be untouchable. SOAs must be designed to co-exist with these existing systems as simple and painless as possible.
6. Understand the strategic value. Consider following benefits: ability to make more informed and timely decisions, creation or automation of new business processes across organisational boundaries, reduced medium-term cost for support, maintenance and 'additional projects'.
7. Buy - don't build. Total Cost of Ownership (TCO) is likely to be higher for build systems (experienced developers, scarce skills), while bought technology is ready for use much sooner. Bought systems are more capable of being adapted and extended, as they tend to be standard-based and tested to integrate with third party solutions 'out-of-the-box'.

Use these Seven Principles to evaluate competing products or approaches,
or simply to guide SOA development and ensure maximum ROI.

Read more on these seven principles for SOA in the PolarLake paper: Seven Principles of SOA Success

Test Driven Project Management

Rather than limiting test driven development to unit testing (driven by development), the test organisation can explore product launch related issues such as packaging, system configuration, upgrade procedures, and documentation at the beginning of the project.

Keys in a test driven project management process:

Team building

• drive project issues, even it means picking up another department's normal duties
• share project related information with other departments
• invite them to your test planning meetings
• volunteer to help when they are behind schedule
• admit when you are wrong

Establishing credibility with senior management

• if you are under new management, make sure to introduce yourself to all other department heads.
• offer up how proactive you like your organisation to be
• offer to send a link to your weekly report or monthly project review presentation
• always be prepared to share a quick status that will provide them with confidence
• be prepared for tough questions and bring along supporting data to back your report, it will also improve your confidence going into the meeting
• focus on the big picture, avoid personal issues, playing the blame game, trying to solve problems in the meeting, keep interactions brief
• show respect, always arrive early to meetings, listen actively, and follow-up.

risk management and reporting

• prepare and maintain a list of project risks and a mitigation plan
• escalations are intended to raise awareness on a company problem and not be used to blame others
• any risk that later becomes an issue will need to be reported as early as possible.
• make sure you notify the department responsible for the issue and offer to help resolve it
• provide trend data, incoming defect rate, defect resolution rate, test summary data
• when raising an issue, focus on the business impact
• publish results frequently and preferably online

rallying the test organisation

• be involved wit actual beta trials
• volunteer to demo the product in your lab to potential customers
• sell your team in senior management meetings, use their names, introduce them to the executives
• share a compliment received from senior-management with your team

Through test-driven project management gain visibility, credibility, popularity, feedback, participation, and confidence throughout the organisation.

Read the complete "Test-Driven Project Management" paper by Scott Lazenby on www.stickyminds.com