How can we teach managers how Software Development works?

Question

In my current company the management does not understand how software development works. You may have heard the quote:

"But why can't we develop this from a external company? Ferrari does not produce their screws themselves!"

Which is somewhat correct, but does not apply to Software development.

I am getting tired to explain this over and over, and I'm looking for resources which I can pass to the managers to get a feeling about how Software development works. In lieu of books or resources, good anecdotes will do.

Answer 1

Have them read "The Mythical Man Month" by Fred Brooks

Answer 2

Peopleware: Productive Projects and Teams (Second Edition) would be my suggestion for a book.

SDLC is useful if you want to give them building blocks. This should be followed by whatever specific methodology or practices your company uses such as Agile, Waterfall, Scrum, or Extreme Programming, to name a few examples.

Answer 3

It sounds like the manager is stuck in a manufacturing mindset, instead of recognizing development as a creative process where thinking and doing is more or less the same.

I'd reply to the outsourcing suggestion with "writing the specification is roughly equivalent to writing the final solution. If we outsource the development, we'll pay twice for the same thing."

Answer 4

In my experience when management starts asking this type of question it is a symptom of something far deeper: it's not that they don't understand software development, it's more that their perception is that they are not seeing any value-add from the IT department.

Note that I use the word 'perception' - you may be supplying a tremendous service, but if the user's perception is otherwise then you are, for all intents and purposes, failing. [Spoken by someone who has been screwed by 'perceptions' on more than one occasion ...]

I have worked at several companies that faced - and overcame - the perception problem. Unfortunately there is no single solution, other than to start by identifying the problem areas and then applying some creative thinking to the solutions.

Answer 5

You might try to point out that Ferrari produces thousands of identical copies of the exact same screw. When you want to write an thousand copies of the exact same software, outsourcing is a great way to go. Alternatively, you might try, "Does Ferrari have its world-class engines designed in India?"

Obviously, there is something to be said for offshore outsourcing. Otherwise, it would not be burgeoning like it is. In my experience, it works best for projects in which requirements are very well known and can be precisely specified. It also works best when you are willing to put the time in to develop a long term relationship with your offshore partner. The first offshore project rarely goes as expected. But, once the initial communication and process hurdles have been overcome, an efficient process can ensue.

Answer 6

Just to share an anecdote, the last company I worked for had a nasty habit of offshoring development to the lowest bidder. The goal here was to get the software out the door as quickly as possible for the lowest cost. The mighty Project Triangle gives you the option to do any project fast, good, or cheap (choose any two) -- having exhausted two sides of the triangle, we had to sacrifice on quality.

We were selling bank software to small banks, and we were very happy when our Indian contractors were able to develop one of our huge money-making projects very quickly. As is usual, bugs were reported, and bug-fixes were fairly rapid -- usually we'd get a patched EXE within a few hours.

Things were going swimmingly for about 6 months. Without warning, the quality of our product began to nosedive: every new bug fix introduced three new bugs, outstanding bugs crept into the quadruple digits, features were taking longer and longer to developer, the application was unstable, and our customers were unhappy. It got to the point where bank presidents were calling up the president of my company in tears because our teller software was crashing 40-50 times a day which prevented tellers from doing their job. Banks were threatening to switch vendors, and the offshore contractors were unable to fix bugs fast enough. Since India couldn't do their job, we decided to do it for them: we requested access to the source code, and we laid eyes on the 130 KLOC of spaghetti code, it became immediately obvious why the application was so buggy.

We terminated our contract with India and went into crisis mode for a while -- 12 months of in-house development later, most of the original code was re-written to a slim 35 KLOC of bug-free, beautify code.

My company learned its lesson: we outsourced another major money-making project to India, but instead chose Time and Quality at the expense of cost. The accountants shared some inside knowledge with me, and I found that we paid our offshore contractors $50/hr/developer. India developed the application for 3 months to get the architecture in place, and from there we collaborated with India for the next several months to finish the product.

When I had a chance to see the code produced by our $50/hr contractors, it was very impressive, well-written, type-safe, well-documented, and used a sophisticated IoC container to handle the complex UI. The total cost to fund the project was about the same as our projections for hiring contractors in the US.

The lesson here is that "you get what you pay for." Maybe, to a lesser extent, we can take some advice from Joel who says "If it's a core business function -- do it yourself, no matter what."

Answer 7

It's obvious you don't work for a software company but rather a place that develops its own solutions. I've worked at a place like this and with a similar manager. Before I get into the real answer, without any details otherwise, the manager's statement is correct -- it's countering not-invented-here syndrome. It appears the manager is more concerned with your team assembling the solution and not getting too deep into something that could be produced by someone else at a discount.

At a company where the money doesn't come from directly from software, your role as a developer is to make sure you aren't needed. It sucks if you want to stay there forever but 2-3 year stints at companies like this (should) look good to other companies like this -- you take the job and work your way out of it by producing quality code that needs very little maintenance. With this in mind, your response should be Yes, we should try outsourcing this part of the project. It may not work out (be sure that's an escape clause for any deadline) for various reasons (cost, timeliness, creating a detailed spec, etc.) but you should try it.

Your situation parallels with my experience. The problem is that we didn't have a very good development methodology. We had an ideal setup for Scrum and you probably do too. The best way to educate your management is to get them involved in a successful process. Preaching software engineering in general is just going to be a waste both their and your time.

Bottom line: This doesn't sound like a company where you should have a long tenure. Work your way out of a job, pad your resume, and move on.

Answer 8

Malax wrote:

"But why can't we develop this from a Indian company? Ferrari does not produce their screws themselves!"

Which is somewhat correct, but does not apply to Software development.

Ah, but it does!

If Ferrari did produce it's own screws, they might get higher quality screws, but they would spend much more money maintaining the screw manufacturing plant.

Or if they suddenly jump into screw manufacturing, knowing nothing about the domain, they might even produce worse quality screws that cost more when starting out.

Outsourcing does work. Providing that you're outsourcing to a provider that knows what they're doing.

If your management looks hard enough for a good service provider with a credible record (the provider has done something similar for other buyers with good results) in whatever you're trying to get done, they will, definitely get it done easier. It doesn't matter where the service provider is located.

A little addition from the comments section:

Mobbit wrote:

I don't doubt that outsourcing might work. But I don't believe that it works for your core >products/components. Like the engine or design of a Ferrari. Screws or seats can perfectly >be outsourced. You still would have to find a partner that delivers you the right quality >at a reasonable price. In terms of software screws would be libraries and seats perhaps a >service or larger component you add to your product. – Mobbit 2 hours ago

Ah, but it DOES work.

Software Development is design, followed up by code. You: Mr. American have a design that you believe can work. Why do you assume that an American programmer would be better than an Indian programmer in executing that design? If an Indian programmer can execute the same design, but cheaper, why would you not use the Indian designer?

The difference in cost between an American and Indian developer isn't because Indian developers are of lower quality, it's because life is cheaper in India, and thus engineers are paid less than the average American.

Full Disclosure: I live and work in India.

Answer 9

Outsourcing can provide a shortcut to a more competitive product, but it typically contributes little to building the people-embodied skills that are needed to sustain a product leadership The Core Competence Of The Corporation

just found this great article about this topic.