Are Programmers Really Engineers?

-->

“Software Engineering” - Whatever That Means
If a programmer hands you her business card, it probably won’t list her title as “Programmer;” It is more likely to read “Software Engineer.” This raises the interesting question: does a programmer’s daily job rise to the level of an engineering discipline? I think it would be more accurate to call programming an emerging engineering discipline.

Evolution of the Field
Since around 1975, various people have tried valiantly to impose discipline on the chaotic, egocentric, idiosyncratic practice of programming. And just at the turn of the century some professional institutions have started to establish the core competencies that would let a programmer call herself a software engineer.

Vision of the Future
Will we see the transformation complete: will programmers be licensed and regulated like other engineers? Personally, I think it’s too early to bet one way or the other - programmers are remarkably individualistic and there will be be very strong resistance to regulating what they regard as their craft. On the other hand, offshore development and the rise of software-based lawsuits are changing the landscape much as barbed wire changed the American west of the 19th century. If you’d like my prediction, ask me again in a decade.

Today’s Situation
But if you are going to work in the world of the programmer, you’ll have to understand some of the standard ways in which complex software is constructed. If you want to sound erudite, you can refer to them as “software development methodologies” or “development models,” but if you’re talking to a programmer you’re better off asking, “So, how do you folks build software around here?”

About the Author
Bruce Taylor is the owner and principal of WorkingInUnison, an Organizational Development consulting firm located near Boston, Massachusetts. Bruce helps software organizations of all sizes to create low-stress, supportive, adaptable working environments, so that the engineers, leaders, and managers can work as effectively as possible. He provides executive coaching for senior managers who are creating superior organizations, management coaching for technical leaders who are adapting to new agile practices, and individual coaching for engineers who are upgrading their skills. Bruce has a Masters in Computer Science from Duke University, a Masters in Community Psychology, and a Certificate in Job Stress and Healthy Workplace Design, both from the University of Massachusetts. He can be reached at http://workinginunison.com or at brucetaylor@workinginunison.com.

Article Source: http://EzineArticles.com/?expert=Bruce_Taylor

Posted in Agile Software Development, Industry, Planning | No Comments »


Choosing an Outsourcer

It is difficult to choose an offshore outsource provider because it’s hard to tell the difference between good and bad computer security. By the same token, it’s hard to tell the difference between good and bad medical care. Because most of us aren’t health care experts, we can sometimes be led astray by bad doctors who appear to be good. So how do we choose a doctor or a hospital? I choose one by asking around, getting recommendations, and going with the best I can find. Medical care involves trust; I need to be able to trust my doctor.Security outsourcing is no different; companies should choose an outsource provider they trust. Talking with others and asking industry analysts will reveal the best security service providers. Go with the industry leader. In both security and medical care, you don’t want a little-known maverick. Companies buying security services should also avoid providers that have conflicts of interest. Some outsource providers offer security management and monitoring. This worries me. If the vendor finds a security problem with my network, will the company tell me or try to fix it quietly?

Companies that both sell and manage security products have the same conflict of interest. Consulting companies that offer periodic vulnerability scans, or network monitoring, have a different conflict of interest: they see the managed services as a way to sell consulting services. (There’s a reason companies hire outside auditors: it keeps everyone honest.) Providers offering combined management and monitoring services will be among the next to disappear, I believe. If a company outsources security device management, it is essential that it outsource its monitoring to a different company.

In any outsourcing decision requiring an ongoing relationship, the financial health of the outsource provider is critical. The last thing anyone wants is to embark on a long-term medical treatment plan only to have the hospital go out of business midstream. Similarly, organizations that entrusted their security management to Salinas and Pilot were left stranded when those companies went out of business.

Modern society is built around specialization; more tasks are outsourced today then ever before. We outsource fire and police services, government (that’s what a representative democracy is), and food preparation. Businesses commonly outsource tax preparation, payroll, and cleaning services. Companies also outsource security: all buildings hire another company to put guards in their lobbies, and every bank hires another company to drive its money around town. In general, we outsource things that have one of three characteristics: they’re complex, important, or distasteful. Computer security is all three. Its distastefulness comes from the difficulty, the drudgery, and the 3 a.m. alarms. Its complexity comes out of the intricacies of modern networks, the rate at which threats change and attacks improve, and ever-evolving network services. Its importance comes from this fact of today’s business world: companies have no choice but to open their networks to the Internet.

Doctors and hospitals are the only way to get adequate medical care. Similarly, offshore outsourcing is the only way to get adequate security for today’s networks.

About the Author

John Parker - For further information on offshore outsourcing and offshore software development, please visit http://www.a1technology.com .

Posted in Industry, Planning | No Comments »


The Pitfalls and Perils of Pair Programming

Pair programming: People either love it or hate it.

The concept of pair programming first became popular thanks to “extreme programming” or XP—a set of practices that supposedly allows companies to develop software in a more efficient, more “agile” manner. Proponents of XP claim that it allows programmers to respond to changing or ambiguous software requirements without sacrificing quality. Skeptics disagree, arguing that these alleged benefits are either illusory or exaggerated.

XP proponents argue that two programming heads are better than one—that two software developers working together will tend to produce better, more reliable and more maintainable than a single programmer working alone. This practice is known as pair programming, and at first glance, it sounds like a great idea. Personally though, I think that it smacks of a “one size fits all” mentality. That is, it assumes that two programmers working in concert will indeed be more efficient and that they will produce better results. I think there is good reason to believe otherwise.

The much vaunted Williams study

XP fans typically point to an infamous study headed by Prof. Laurie Williams at the University of Utah. In this study, Williams concluded that pair programming takes 15% more time than solo development, but results in software that is 15% better. They argue that this modest increase in development time is a small price to pay, since better code quality means that less time and effort will be required later down the road – during testing and maintenance, for example.

I think that there are numerous problems with this study, though. How did the researchers gauge software quality, for example? The used the length of code as the quality metric; that is, the shorter the source code, the better they deemed it to be. The reported, “[The paired teams] consistently implemented the same functionality as the individuals in fewer lines of code. We believe this is an indication that the pairs had better designs.” I think this is a hasty leap of logic, to say the least!

Does shorter source code exhibit greater quality? Sometimes, perhaps. However, one could just as easily speculate that the longer code contains more bug fixes and safeguards. In addition, adding more code lines – to implement a design pattern, for example – can make the software more efficient or easier to maintain. I think that the presumed correlation between code length and lack of quality is poorly justified at best.

The study also exhibited a severe case of participant bias. The students in a class were asked if they preferred to work in groups or alone. 35 of the respondents said that they preferred collaborative working; of these students, 28 of them were selected to constitute the pair programming experimental group. The remaining seven were placed in the solo programming group, i.e. the experimental controls. This created a strong experimental bias; all of the pair programmers were willing volunteers, whereas some members of the control group were there reluctantly.

What’s more, 13 out of the 14 pairs were self-selecting; that is, students were allowed to pick their partners willingly. Once again, this biases the results, since participants are likely to select partners with whom they are particularly compatible.

(Interestingly enough, these biases could have been easily avoided by assigning pairs randomly. I don’t wish to cast aspersions; however, I can’t help but wonder if Prof. Williams and company might have unconsciously biased their experiment to demonstrate the superiority of pair programming.)

Short-circuiting the creative process

In short, the supposed evidence for increased productivity under pair programming is questionable at best. In addition, we should ask if there’s any reason to believe that pair programming can be counter-productive or otherwise harmful.

I believe that it can be. Pair programming can certainly help people catch or prevent bugs; as the story goes, two pairs of eyes are better than one. When faced with a thorny problem though, one often needs to let the problem percolate in one’s brain for a while before arriving at a proper solution. Often, that’s how creative minds operate; they need to let their minds sift a problem first before attempting to fix it.

With pair programming though, this process is short-circuited. Instead of letting one’s mind digest the problem in due time, pair programming puts pressure on people to arrive at a solution more quickly. Sometimes, this may produce better results; however, it can also have the opposite effect. I suspect that for the most creative minds, this kind of pressure can stifle creativity rather than hinder it.

But wait! Isn’t there power in numbers? Aren’t there times when the best results are produced by having people brainstorm and confer? Certainly… but these “meetings of minds” don’t have to occur during the programming process. They can occur during planning sessions, during design reviews, or when sitting around a lunch table. We shouldn’t dispense with group troubleshooting and design; we simply shouldn’t force this to occur at the coding stage. That can do more damage than good.

What’s more, the most creative minds often need a measure of playtime – an opportunity to play around with the code, tentatively exploring various options and letting one’s mind roam free. This can be difficult to do when another programmer is looking over your shoulder. After all, what should we do – explain and discuss every tentative step? For a creative mind, this can be stifling indeed.

Conclusion

In short, I think that the evidence for pair programming effectiveness is questionable and overblown. I also think that there’s good reason to believe that pair programming can stifle the creative process, instead of helping it. Can pair programming be helpful? Certainly… However, when forced upon people, it becomes a “one size fits all” strategy—and unfortunately, a single size can’t possibly fit everybody, no matter what the salespeople say.

About the author:

V. B. Velasco Jr is a senior electrical and software engineer at a small biotech company that provides ELISPOT plate readers, serum-free media and frozen human PBMCs.

Article Source: http://EzineArticles.com/?expert=V._Berba_Velasco

Posted in Agile Software Development | No Comments »


Using an Agile Software Process with Offshore Development

If you have been implenting or considering Agile Software Development Process with Offshore Software Development Providers, this article from Martin Fowler, might be interesting to you.

An excerpt

For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we’ve discovered that we can make it work, although the benefits are still open to debate.

Agile Software Process with Offshore Development

Posted in Agile Software Development, Implementation, Planning | No Comments »


Ten Outsourcing Fears and Steps to Ward Them Off

Outsourcing your non-core operations to a service provider has ceased to become a prerogative. Almost everyone is doing it even the top Fortune 500 companies. Definitely, outsourcing has become another option for business viability and survival.Apart from lowered cost and enhanced quality of work, outsourcing enables companies to tap the expertise of the outsourced service provider into its own operation, thus the outsourcing company stands to benefit more than just getting its non-core jobs done by an outsource provider. Yet, as beneficial as it seems, there are attending risks. Just like an ordinary business transaction, outsourcing, too has loopholes.

Here are ten (10) outsourcing risks identified and the steps to ward them off:

RISK #1: Outsource provider’s track record.

Taking a closer look at the outsource provider’s number of years in the outsourcing industry, size of his company as to number of his employees when he started out compared to his present organizational structure, taking into account the ratio of employees’ turn-over, his financial background, etc… - all these are determinant factors of an outsource provider’s track record.

RISK #2: Competencies.

Is the outsource provider competent to deliver quality services? Is the outsource service provider ISO9000 compliant, or are there verifiable certifications from competent independent agencies like CMM, issued in its favor? What are the procedures the outsource service provider undertake to ensure that it delivers quality service?

Clients’ references are the best source of information concerning competencies of the outsource service provider. Their satisfaction guarantees yours, too.

Editor’s Note: See Quality Certifications and What they Mean in Software Development for more info

RISK #3: Hidden costs.

The apparent reason why you outsource is cost. Undeniably, outsourcing cuts down cost, but be wary about hidden costs that can spring like panthers aiming for your throat!

Areas to watch include connectivity expense, infrastructure maintenance and development, transition cost, licensing and consultancy.

RISK #4: Meeting deadlines.

Are commitments attainable? Is your outsource service provider apt to the challenge of delivering to you the service you need within prescribed, and agreed upon, time frame?

RISK #5: Data safety.

Now, caution should be emphasized here. You will be sharing information about your business with your outsource service provider. Is non-disclosure agreement an issue? Get an affirmative response from your outsource provider that any information, data or work processes that concern your business should not be disclosed to a third party. A privacy statement should be included, and form part of your contract with him.

Your team at the outsource service provider’s company should undergo pre-hiring orientation which will inculcate their adherence to non-disclosure of vital information and privacy agreements.

Security settings such as firewalls, anti-spam ware, access controls and data encryption should be discussed and agreed upon as well.

RISK #6: Contingency Plans.

Find out about contingency plans. Does your outsource service provider have one in place?

Your outsource service provider should have considered measures to undertake before any contingency strikes. Equally important are its recovery plans. How well does your outsource service provider expect to continue with its business should a disaster occur?

Businesses are beset with risks. When you outsource, you become involved with whatever risk your outsource service provider face up to. It is best to know that you will be dealing with a service provider that has foresight. This is a sign of maturity and responsibility.

RISK #7: Transparency.

Always invoke transparency between you and your outsource service provider in all phases of your business undertaking. This will immobilize intrigue, dissension, and will affirm trust.

Is invoicing done on time? Are contracts feasible?

Eradicate minor flaws as they take root, by being transparent and trustworthy. This will be the ground upon which your business will flourish.

RISK #8: Adherence to labor laws, state laws and regulations.

Your outsource service provider should operate within the legal tenets of its own country. Its non-conformance of state laws, regulations, ordinances, etc… will affect you, if not legally, then on moral decency.

You as the outsource service provider’s client should ensure your moral ascendancy in environmental concerns, and employees’ welfare.

RISK #9: Employees’ Issues.

Cross-training of employees is necessary to avoid disputes and needless work stoppage. As most outsourcing is done to foreign countries, employees should receive orientation as to what they can expect from a foreign client, as well as the client understanding situational factors, such as time-zone difference, length of work hours, etc… from the point of view of employees.

RISK #10: Cultural Match.

Akin to risk No. 9 is finding a “match” or a “fit” between the outsource service provider and the client. Cultural factors can influence, positively or negatively, the outcome of the working relationship. For a suave interaction, the “fit” should be found.

A mismatch can cause problems ranging from pre-termination of the contract, faster turn-over of employees and a host of other concerns. Any of these reasons means loss for both parties.

Most common reasons why outsourcing goes sour are outsourcing services getting expensive or poor performance by the service provider.

The key is to choose wisely and carefully. Avoiding guesswork will eliminate unnecessary expense, wasted time and efforts. Selecting a service provider who possesses integrity, honesty and competence remains a sure-fire formula.

About the Author

Steve Arun is an Internet Marketing, Client Account Specialist for KPOWEB, an Offshore Outsourcing Consulting company provides virtual dedicated staffing to small business. Go now to KPOWEB Offshore Outsourcing Services, the IT outsour

Posted in ISO 9001:2000 , Planning, SEI CMM | No Comments »