IT Job Market May Improve in 2011

CareerBuilder surveyed IT managers in the United States in charge of hiring. The job site subcontracted the interview work with these IT managers out to Harris Interactive, which did surveys from November 15 through December 2, 2010.

When the numbers were all tabulated, 42 per cent of the managers contacted said they planned to add permanent, full-time IT people in 2011, up from only 32 per cent who said they would hire full-timers in the IT department a year ago. Sixty-six per cent said they will be increasing the compensation of their existing IT staff in 2011 – the average expected pay raise works out to 3 per cent – and 56 per cent of those polled said they were worried about losing their best employees as the economy continues to improve. Salaries for new positions are expected to go up by between 1 and 3 per cent.

Simple Solutions

One of the hardest things to do is to discover the simplest solution to a problem.  To often software developers come up with the most complex solution instead of the simplest one.

The simplest solution is the solution with the least amount of functionality to solve the problem.   This makes the solution simple to design, simple to code, and simple to test too.   Another advantage of simple solutions it is easy to document and communicate.

What is the purpose of Software?

My friend Grant Rule posted an interesting question on LinkedIn. He asked, “What is the purpose of software?” To me the answer is obvious and the purpose of software is to solve problems. Too many software applications are being built without a clear problem to solve. Too many in the field of software development focus on what the technology can do.

Let me make an analogy for you. I travel a lot internationally and I went to my bank (Bank of America) and asked for a line of credit. The banker said,” of course we can give you a line of credit” and then she asked, “what problem you are trying to solve?” I explained that I travel a lot international and run up large expenses. The problem, in my mind, was the time between when I was paid by a client and I had to pay my credit card bills. The solution, in my mind, was a line of credit. Notice I had the problem and solution well in my mind. Then said asked me if she could offer a potential solution. She suggested, “Why don’t you ask your clients for a percentage upfront to cover your expenses?” It turns out I did not need a line of credit at all. I have taken her advice and it has worked well.

To many “customers” of software applications do not know what problem they are trying to solve and therefore cannot offer a solution. Tom Kelly (The Art of Innovation) points out too customers do not have the ability to articulate what is wrong and especially what is missing. So if the purpose of software is to solve customer problems, and customers cannot articulate what is wrong and what is missing, then exactly who is suppose to articulate the problem and potential solution?

What is the average cost to develop software — It depends

I get asked the question, “What is the average cost of develop software?” all the time.  The answer it depends.

1.  When people ask the average what they are asking is what is the average unit cost of software.  This is a similar question to what is the average cost per square foot of construction.  I use function points, so the question becomes what is the average cost per function point to develop software.    The average dollars per function point is one way to determine the average dollars per unit of software developed.

2. The average cost per unit of software developed depends on several factors.

2a.  The type of business the software supports.  The unit cost of software is going to be different for insurance industry and the aerospace industry.  The same is true with construction.  The average cost per square foot  to build a mission control building for NASA is not going to be the same as the cost per square foot to build an insurance office building.

2b.  Location, Location, Location.  Like real estate the cost per unit of software is going to depend on where it is built.  If the software is built with cheap labor (the main input), then the cost will be less.  Of course it depends if the cheap labor is of equal productivity.  If the cheap labor is half the cost and half as good, then you really do not gain anything from using cheap labor.

2c. Duration.  The duration impacts cost too.  Not only development costs but maintenance costs.  If the the software has to be developed as soon as possible it is going to be expensive per unit.

Actually there are about 50 other factors that impact cost, but these are three big ones.

Read more at Reboot! Rethinking and Restarting Software Development.

What we have here is a failure to communicate

Why do bureaucracies emerge in organizations and often overwhelm it?

The real question in my mind is, “What is the root cause for an organizations to have too much bureaucracy?”  It is not like organizations or more correctly individuals within organizations wake up proclaiming we need more bureaucracy.   People do not say, “We need to burden teams with status reporting, forms, procedures until we reach a point in time where everything comes to a screeching halt.”

The idea of small autonomous teams that are unhampered by bureaucracy is not new.   During the 1990’s there was a software methodology called Rapid Application Development (RAD) and today the buzz is Agile. This idea of limiting bureaucracy is not limited to software development.  Going all the way back to the 1940’s there were teams called “Skunkworks” at Lockheed Martin.   The point being idea of self directed teams is not unique to software development and not a new idea.

Some of the clues for burdensome processes come from the word bureaucracy itself.  The term bureaucracy came into use shortly before the French Revolution of 1789, and from there rapidly spread to other countries. The Greek suffix – kratia or kratos – means “power” or “rule”. Does it turn out that bureaucracies are the result of power and rule?

My experience tells me it is not that simple. The root cause for bureaucracies is the result of poor communication.  The cause of bureaucratic burdensome processes is the result of a failure to communicate.   An organization can eliminate burdensome processes, but it does not resolve the problem of communication.  If root causes are not addressed, then problems will never be resolved.

The bottom line is  bureaucracies emerge because of poor communication.  Go though the two links below and look at the recoomendations.  We will begin to notic the opposite is done in software development.  As an example, it is recommended to avoid jargon.  How often is that done in software development.

99 Ways to Improve Communication http://www.getinfrontblogging.com/communication/99-ways-to-improve-your-communication/

Improving Communication Skills http://achievesuccessforlife.com/41/improving-communication-skills/

Sources

http://en.wikipedia.org/wiki/Skunk_Works

http://en.wikipedia.org/wiki/Rapid_application_development

http://en.wikipedia.org/wiki/Bureaucracy

Methodologies and Fad de Jour

According to a recent study Agile is growing in popularity and not long ago the Capability Maturity Model (CMM) was the fad de jour. CMM was based upon sound scientific methods with plenty of data to support its case and Agile is based upon anecdotal evidence. It is not like there are small tweaks of ideas because the difference between CMM and Agile are tremendous.

What is it with software development that causes it to flirt with methodologies as often as weight loss methods? It is like the industry is floundering. It seems that some of the major consulting firms and experts in the field were proponents of CMM not long ago singing the praises of Agile. There seems to be an effort to support and to promote what is popular instead of what is right.

I believe the clue lies in why so many individuals experiment with weightless methods. Consumer Reports declared Weightwatchers the best success weight loss program, but its success rate is low. It is estimated that 95% of those using Weightwatchers eventually return to their old weight. It turns out people (especially Americans) do not have disciplined eating and exercise habits. It is so easy for us Americans to be overweight, to sit in front of the TV, or to spend countless hours surfing the internet. Our portions at restaurants are supersized and there is often an endless supply of snacks at work.
We could excuse the ebb and flow of methodologies on fact the field of software development is in its infancy stages, but I am not sure that is a good idea. In reality, those software companies that are the most disciplined have the highest rates of productivity and quality. This is true of world class athletes and musicians as well. It is especially true of world class golfers. A logical question is what does discipline look like in software development?

What makes software unique from other industries and disciplines is it is so easy to be undisciplined in our methods. It is easy to change a line of code compared to changing a physical structure or a building. The rhetorical question becomes if physical structures of a building could be changed as easily as software can be changed, then would architectural firms adopt the methods of software development?
I have studied hundreds of organizations around the globe as part of a merger or acquisition. It turns out those that are the most disciplined with repeatable processes are the most successful. It is critical to note that being disciplined does not guarantee success. It seems the missing ingredient is customer knowledge. The formula becomes those organizations with discipline and those that study the customer are the ones with world class performance levels.

Yet the unanswered question remains.  What are the reason so many software development organizations flirt with so many methodologies?

http://www.googobits.com/articles/625-the-skinny-on-fad-diets-what-really-works-what-definitively-doesnt.html

http://www.RebootRethink.Com

http://www.internetnews.com/dev-news/article.php/3841571

http://blog.nayima.be/category/agile/

http://www.sei.cmu.edu/cmmi/

Drinking from the Fire Hose of Information!

Drinking from the Fire Hose of Information or five things to do to improve status reporting.

When providing status of a problem it is important to provide the right level of detail, so the situation can be easily digested. A lot of technical team members provide status and it is like trying to get a drink of water from a fire hose. They tend to provide so much technical information the person on the receiving end is totally drenched in information, but thirsty for status.

 The objective is not that everyone understands the technical nuts and bolts of the problem; rather, the objective is to gain confidence the problem is being handled appropriately. Status should include items like:

1. Who are the customers impacted?
2. Have the customers been notified?
3. Have the customers been shown evidence the problem has been resolved?
4. What caused the problem?
5. What steps have been taken to make sure the problem does not reoccur?

Read more at Reboot! Rethinking and Restarting Software Development

Software Librarians

There is a job title in the software domain called software librarian. I searched for the job title of software librarian on Monster.Com.   It does not seem that software librarian jobs require any background in library science.   Instead the job description indicated they wanted someone who could code.  When I searched for medical librarian or law librarian the following appeared in every job description.

You must possess the following requirements and experience to succeed in this position: Master’s Degree in Library Science from an ALA accredited program.

What is the motivation for the fields of medicine and law to require a Masters in Library Science to organize their documents while there is no requirement whatsoever for the software industry?   These other industries have realized how critical it is to organize knowledge, so it can be retrieved and reused.

I suggested to a client they hire a librarian or two to help them organize their software application.    He looked at me and asked me one of those obvious questions, “where do we find a librarian.” I suggested he look for a librarian at the library which they did.  They hired two librarians to consult and help establish a numbering system similar to the Dewey Decimal System for their software applications.  Like the DDC their internal numbering system was a faceted system.  This allowed a lot of cross-referencing of documents. In the end they had an online system where they could search for documents by a specific part of the application.

A librarian, with a Masters degree in Library Science, makes between $36,980 and $56,960 per year.[i] The average salary of a software developer is around $69,240.  You can get a librarian for less than a programmer and they are going to be twice as productive (maybe more) as a software developer when it comes to organizing.

Read more at Reboot! Rethinking and Restarting Software Development

http://www.davidleeking.com/ – Interesting ideas on design and organization of website and information.

http://theshiftedlibrarian.com/ – interesting ideas on how information is shifting.  It is coming to us in a variety different ways now.

---

[i] Bureau of Labor Statistics http://www.bls.gov/k12/print/read04.htm#pay

http://www.ala.org/

Movie Making and Software Development

The role of the project manager and software manger are often missed understood. Movie making and software development are very similar types of creation.  A brief examination of movie making and comparing the roles of director and producer will give some insight on the differences of the project manager and software manager.

The director of a movie is similar to an IT Manager.  They are responsible for day to day activities.  It is common for many directors to not have any acting experience.  For example Steven Spielberg, winner of numerous academy awards, has never acted.  On the other hand Clint Eastwood was an acclaimed actor prior to becoming an award winning director.  The directors, like an IT manager, is responsible for the management of staff.

There are many technical aspects the film producer need to coordinate.  Besides the actors and actresses it is important to have the right film crew, lighting, sound, editors, animators, so on and so forth.  The producer may or may not have intimate knowledge of any of the technical roles.  The software project manager is responsible for getting the right business analysts, coders, testers, software engineers for a project.

Producers like the software project manager are responsible for the planning and the execution of the budget and insure the project comes in on budget and schedule.  An executive producer may coordinate the activities of several producers similar to the role of a project management office.

———————————————-

Who does what? http://www.directortom.com/director-tom/2007/8/17/executive-producer-producer-director-who-does-what.html

A production manager – a rose by any other  name

http://filmindustrybloggers.com/blog/2009/10/13/the-production-manager-a-rose-by-any-other-name%E2%80%A6/

Benefits to documentation (yes there are some)

When application documentation is given meaningful names and numbers, it can be found easily. Software organizations need to establish a standard naming convention for documents and the application.  Documents need to be named using some agreed upon standard and a numbering system. 

By definition a complex software application is difficult to understand and needs to be documented well.  Yet, I have heard comments like, “our software is too complex to document.”   If your software application is too complex to document, then the software application is too complex to understand and your software needs to be simplified.  If your software application is too complex to document, then how will the complexity be communicated?

 No one wants to be a software archeologist.  One problem with unorganized information is it can’t be found, so there is a lot wasted time spent pecking around looking for the right document or trying to find the right person to talk to.   Another problem is if your documentation can’t be found, then redundant functionality is often created.  Of course creating redundant functionality is a waste of time.    The real benefit to the organization of documentation is reducing wasted time and spending more productive time on projects.  This, of course, improves profitability. 

 Another benefit to organized documents is the ability to reuse parts of the application documentation.   Reuse has been a hot topic in software development for sometime and it should not be limited to just the code.   Everything related to past projects can be re-used including requirements, test plans, test data, even project plans can be reused.  Reuse is a good idea and it does improve both productivity and quality.   Artifacts that can’t be found can’t be reused.  Those companies that have mastered reuse see a natural increase in their productivity and profitability.

 Read More at Reboot! Rethinking and Restarting Software Development