People Related Questions

People Related Questions

1:

What is the key to successfully managing software developers?

A:

Give them a manager who understands what they want to do and how they want to do it. There is no one less motivated to the success of your project than a developer who feels he or she is being asked to do something the wrong way by a manager who doesn't understand the technology to begin with.

2:

Should I centralize or decentralize my applications development group ?

A:

Centralized application development groups are often criticized as being too unresponsive to departmental needs. Decentralized application development groups may not be large enough to support the wide range of software specialists needed for modern development projects. In addition, decentralized organizations may also lead to duplicate functionality. A good compromise is to centralize enterprise-wide applications development (payroll, finance, etc.) while letting each large department maintain its own decentralized development group for department-specific applications. "Big" architecture decisions, those that affect any development group, should be made by a centralized architecture team.

3:

Should I outsource my applications development?

A:

For starters, don't outsource your software architecture. This is so crucial to development and tied to business knowledge that it should be kept in-house. You should consider outsourcing to fill peak development demands or specific specialties when it is not economical to maintain an in-house staff for these needs.

4:

How much training should my developers get each year?

A:

This, of course, varies considerably with the skill of your developers and the complexity of the software you are developing. Organizations consistently ranked at the highest levels of the software capability maturity model (see Chapter 8) allocate up to 25% of a developer's time for both formal and informal training.

5:

Do good software developers make good software architects or software development managers?

A:

Not necessarily . Some developers who are very good at writing code may never have an interest in becoming software architects or software development managers. One of the biggest mistakes you can make is to try and turn a great developer into a software architect or software development manager when they have no real interest nor the proper training and skills to do the job.

6:

Does a software development manager need to have hands-on software development experience?

A:

In general, the best software development managers started their careers as software developers.

7:

What are the main qualifications when hiring a senior developer?

A:

When hiring a senior developer, excellent technical skills are simply a minimum bar for consideration. We look to senior developers to be the role models and "goto" persons for the rest of a project team. Some of the main qualifications we look for include:

  • initiative

  • dedication

  • flexibility

  • respect

If we had to name a single technical skill we look for it would be knowledge of object-oriented technology. By this we mean not simply being able to write code in an object-oriented language like Java, but truly understanding the concepts of object-oriented architecture, design, and development.
8:

Should you try to breed developers internally as well as utilize external recruitment efforts?

A:

The lack of a strong educational foundation in the basics of computer science, reasoning, and problem solving is one of the most common reasons for poor developer performance. For this reason we do not typically try to breed developers internally from employees that do not have such a foundation. However, we absolutely do transition developers of one type, say Mainframe/COBOL programmers, to developers of another type, e.g., Java programmers. We do this because an experienced developers business and domain knowledge, along with his or her "corporate memory" or culture, and educational foundation in computer science easily outweigh the advantages of most external candidates who might have the exact technology experience required.

9:

How would you structure the organization for proper skills development for young programmers?

A:

Having proper training processes in place is just as important a process for the long- term success of a development organization as is requirements management or configuration management. Each developer, from most junior to most senior, has specific training goals set as part of his or her annual review. In addition, junior developers are given "mentors" when they come on board to help them adjust to the company work environment. Besides spending time with their mentor, all junior programmers or ones new to the organization are given a goal of spending two hours a week meeting with developers, managers, or other employees outside of their immediate work group. This gives them a chance to informally learn from a wider range of people. Finally, in areas were we have two-person offices, we always try to pair a junior and more senior developer in the same office.

10:

How long does it take to train a mainframe COBOL programmer to learn C, Java, or C++?

A:

It depends on how fast they want to learn. One of the ways we select COBOL programmers to transition to web-centric environments is by their level of external interest in the subject. A COBOL programmer who still doesn't use the web regularly and has never requested to take any C or Java programming probably doesn't make a good candidate to transition. Given a good candidate, we find most COBOL programmers can learn the syntax of C or Java with two weeks of formal training and another few weeks of on-the-job training. Learning the syntax of C++ takes about twice as long. However, simply knowing the syntax of C++ or Java doesn't mean a programmer is ready to take on object-oriented design tasks . Once a COBOL programmer has mastered the syntax of C++ or Java, we find it takes another month of formal training and at least four months of on-the-job training, for a total of six months, to master object-oriented programming technology. To become a good object-oriented architect takes at least another year.

11:

In all client/server environments the communication between Applications Development and Production Support is horrendous, and that is putting it nicely . What would you recommend?

A:

The best way to get Applications Development and Production Support to communicate is to get the two groups talking early in the design phase of a project. This is one of the key reasons we developed the Web-Centric Production Acceptance process described in Chapter 13 of this book.

12:

In many companies the Database Administration group reports into Applications Development, in others they report into the operations group, and yet others their reporting is split between both. What would you recommend?

A:

Database administration is closely tied to database design, as many database tuning operations will impact the design of the application and vice versa. We recommend, however, that day-to-day database administration functions be part of the operations group. You should, however, have database designers with hands-on database administration experience as part of your applications development group. For starters, this will help you develop database schemas that are easier to tune for maximum performance and stability. Secondly, this will help your database designers communicate with a common vocabulary with the database administrators who are part of the operations group.

13:

What is the role of the architecture function within Applications Development?

A:

The architecture function with Applications Development should set the high-level application standards that will be used by all enterprise-wide applications in your organization.

14:

How would you structure the architecture function in the organization?

A:

Chapter 6 describes several different ways to structure the architecture function. We generally suggest that you have a small group responsible for setting enterprise-wide application architectures for the entire corporation. Individual systems or projects, however, should have the architecture function integrated into the project team.



Software Development. Building Reliable Systems
Software Development: Building Reliable Systems
ISBN: 0130812463
EAN: 2147483647
Year: 1998
Pages: 193
Authors: Marc Hamilton

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net