Anatomy of a Software Development Role: Deployment

Robert Bogue July 11, 2005 No Comments

The deployment role is a role that is often overlooked much to the pain of the users. The actions of this role are the final step before being able to hand over the code to the users for their first real road test of the solution. It is the deployment person who can have the largest impact on the initial perception of the software for the people who are first trying it out. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

Success here can hide quirks in the solution but failures here can give the wrong impression about the software.

What’s the Deployment role?

A software solution of any complexity will have dependencies that must be present before the solution can be used. Many of these dependencies go unstated. For instance, a Java program needs a certain level of the Java runtime environment installed to be able to run. .NET based applications require a specific version of the .NET framework and common language runtime to run. In the case of database applications specific versions of the software drivers to connect to the software to the database are required. Click here to see how the the Deployment role fits within the full organizational chart.

In addition to these software dependencies, there may also be hardware dependencies. This could include a minimum amount of member, a required amount of hard disk space, access to multiple machines (such as a database server versus an application server), access to the Internet, and more.

http://www.developer.com/java/ent/article.php/3519186

A single Goliath or best of breed

Robert Bogue July 11, 2005 No Comments

No single off-the-shelf system will exactly meet all of your organizational needs. The trick is finding the set of solutions that meet your organization’s needs and that work well with each system within that set of solutions.

Sell the Strategy Before Selling the Tactics

Robert Bogue July 2, 2005 No Comments

You need to sell the strategy of technological innovations both to your group and to the organization as a whole. From there, each tactical battle is easier. The organization will already know the expected result and can visualize the success of each tactic resulting in the goal or goals they want.

“Those who fail to plan, plan to fail” was the old cliché that my English teachers inflicted upon me during my junior high school years. Unfortunately, that only conveys part of the message. When discussing how to lead your group forward in any technological innovation, it’s not enough to merely have a plan; you have to sell the plan. You have to get your group to buy into the plan and be willing to make sacrifices in order to reach the plan’s vision.

Failing to sell the plan will often mean having to sell every action you take. Without a good understanding of the plan, most people will assume you don’t have one and will approach each item as a separate “stab-in-the-dark” attempt to improve things.

You need to sell the strategy in what you’re doing both to your group and to the organization as a whole. From there, each tactical battle is easier. The organization will already know the expected result and can visualize the success of each tactic resulting in the goal or goals they want.

http://www.techrepublic.com/article/sell-the-strategy-before-selling-the-tactics/

Finding the Right Role in IT

Robert Bogue June 27, 2005 No Comments

People’s positions do not necessarily reflect current roles in the organization. In placing employees in a role, it is important to assign them to tasks that fit their capabilities. Whether you are a CIO, director, manager, supervisor, or worker, you have a set of strengths and weaknesses that are uniquely yours.

When I was young, I played soccer, although I didn’t play that well. I never really understood why some players would stay away from the ball instead of chasing after it. I could see the goalie stayed in his place, but I thought everyone else should chase the ball. I found, with experience, that the players who stayed in place were often more effective at what they were doing than those who spent their time running after the ball.

We have the same situation in IT. We need people to stay in roles and positions that leverage their strengths and allow them to be good at what they do. While occasionally the goalies have to get out of the box, their primary focus is guarding the goal. The same is true of your IT staff. They need to stay focused on what they do best and allow others to do what they do best.

Finding everyone’s true position

http://www.techrepublic.com/article/finding-the-right-role-in-it/

Anatomy of a Software Development Role: Quality Assurance

Robert Bogue June 27, 2005 1 Comment

The Quality Assurance (QA) role is the role responsible for guaranteeing a level of quality for the end client, and to help the software development team to identify problems early in the process. It is not surprising that people in this role are often known as “testers”. Of course, the role is more than just testing. It’s about contributing to the quality of the final product. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Quality Assurance role?

The quality assurance (QA) role is one that is focused on creating a quality deliverable. In other words, it is the responsibility of the QA role to make sure that the software development process doesn’t sacrifice quality in the name of completed objectives. Click here to see how the QA fits within the full organizational chart.

The QA role works with the Functional Analyst (FA) and the Solutions Architect (SA) to convert the requirements and design documents into a set of testing cases and scripts, which can be used to verify that the system meets the client needs. This collection of test cases and scripts are collectively referred to as a test plan. The test plan document itself is often simple providing an overview of each of the test cases. The testing cases and scripts are also used to validate that there are no unexplained errors in the system.

http://www.developer.com/java/other/article.php/3515426

Remain Productive by Honoring Commitments

Robert Bogue June 24, 2005 No Comments

Have you ever wondered what happened to that high performing team that you had just a few months ago? Have you ever stopped to think about why it seems like the progress you were making at one time does not seem possible today? These insidious problems can sneak up on you before you know it.

http://www.techrepublic.com/article/remain-productive-by-honoring-commitments/

How to create a technology replacement strategy

Robert Bogue June 24, 2005 No Comments

When you are considering the cost of your organization’s technology, you must consider its life cycle and make allowances not only for the purchase price of the technology but also its support costs.

Life cycle

Every mechanical device has a life cycle. In the early days of the device, there is a period of “shaking out” when a relatively large number of problems will be discovered. This’s why many mechanical devices go through a burn-in period at the manufacturer in an attempt to work out the problems. This is generally followed by a long period of relatively low problems. Finally, a gradual climb in support costs ensues.

Think of it like buying a car. If you have ever bought a new car, or have known someone who has, often the new car has a few kinks. After the first month or so, the car settles down and generally has few problems. Once the car has become a few years old, it begins to develop problems. The problems may be gradual at first but eventually, if you keep the car long enough, you begin to feel that it is nothing but problems.

The technology that you use in your organization is the same way. Every piece of technical infrastructure you have will work well at first, or at least well after the burn-in period, and then slowly start to deteriorate.

This is one of the reasons that older computers need to be replaced — even if they’re still operating fast enough for their users. Eventually, they’ll break down and will need to be repaired or replaced.

http://www.techrepublic.com/article/how-to-create-a-technology-replacement-strategy/

Anatomy of a Software Development Role: Developer

Robert Bogue June 15, 2005 No Comments

In a previous article, The Many faces of the Developer , I walked through some of the different types of developers that there are – different specializations that developers have worked on. In this article we’ll take a look at what the job is in general, how to get it, and what to do once you have it. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What is the developer?

Ask any developer and they will tell you that the heart and soul of the development process is the developer role. Developers are often the huddled masses yearning to create software. They are the workhorses of the whole system creating the code that the other roles only influence. (The exceptions are the development lead and solutions architects who write small amounts of code from time-to-time.) Click here to see how the SA fits within the full organizational chart.

http://www.developer.com/java/other/article.php/3511566

Remain productive by honoring commitments

Robert Bogue June 14, 2005 No Comments