Preparing for a Software Career - Part Two

Sometime back, I had written an article on how to prepare for a software career. Today, there was an interesting comment on that post stating that the advice was generic and could apply to any field of study. Also since most people invest a lot of their time and skills in one particular field, they do need specific advice.

I agree on the point of original selection. People could waste precious years of their lives learning the wrong things and finding themselves at a dead-end one day. So what should a computer science student do?

Here are the possible career options after you finish doing a computer science or computer applications course:

1. Find a job at a start-up, small or medium-sized company or a large corporation.
2. Start your own company.
3. Go into future research and possibly becoming a teacher.

In this article, I will only discuss the first option, primarily because that is the common choice for most people and secondly, I have little knowledge of the latter two options.

If you are looking for a job, the important thing is to maximize your options for getting a job and, to a less immediate extent, maximize your future opportunities after getting the job. Here are the things you need to care about:

1. Size of the job market: If you want to choose between two subjects, find the relative market demand for such knowledge. You can make an educated guess by looking at the postings in various job sites and advertising in newspapers. You can also look at the size and reach of online communities in such subjects. For example, Java has a greater market than Perl and hence is a better choice in that respect, regardless of the actual merits of either language.
   
   
2. Simplicity of the subject. The easier the subject, the greater the supply of talent in the market. And the lower the chances of you landing a job, or getting a good salary. For example, knowing web design (HTML, CSS, etc.) was very much in demand a few years back, but since it was easy to learn and tools became more powerful, it is perhaps not a good career option today.
   
   
3. Popularity trend of the subject: Some subjects have a large market, but they are declining. For example, Perl had a good time in the 1990s, but other open source languages are gaining traction over it. It is also important to recognize temporary upsurges in popularity. For example, Lisp experienced resurgence because of Paul Graham's writings, but we don't know if that is a permanent thing. Also, the use of a language by a highly successful company, like Python and Google, can give a language momentum. 
   
   
4. Is the subject a point-of-no-return? Choose a subject that gives you more options in the future. For example, learning a C++-like language (like Java, C#, etc.) can give you more flexibility compared to other languages. Similarly, other choices that can affect you are your program specialization, your project work, your grades in specific courses, etc.
   
   
5. Can you learn it well? If you have never mastered the basics of a subject, say mathematics, then it is better to stay away from such a course. Otherwise, you will constantly struggle to learn it well. You may end up with bad grades. This could possibly have a ripple effect on the rest of your career.

There is also the question about your personal preferences. You may like one subject or language better than another. It is perfectly fine to make your choice based on that, if that will keep you happy regardless of the outcome in terms of getting a job. In my experience, it doesn't. The worst thing you can do to yourself is to marry yourself to some liking or principle and then face the specter of unemployment.

A problem with making any choice is that you are doing it based on your present understanding of the job market. It is likely that employer preferences may change in the years while you are studying. Academic curriculum changes are slow. So it is important to do your own learning to stay on top of current market happenings.

At this point, I want to return to the points mentioned in my earlier article. Having made your choice, you have to work extremely hard to learn the subject well. Secondly, learn how to communicate and interact well in a professional setting. The knowledge and the people skills will make a significant difference in your ability to get a job.

Remember that when you are applying for a job that is advertised for straight-out-of-college, then your advantage over your competition is

• How much you know: Your knowledge.
• How much you prove you know: Your ability to communicate your knowledge, talents and intelligence. No interviewer can scan your brain. You have to prove yourself to him/her.
• How much you can use what you know: Any projects you have done or knowledge outside what has been taught to you.
• How much you will get along: Your attitude and demeanor during the interview.

Once you get the job, the best way you can improve your career is to continuously learn more and adapt yourself to changing business conditions and work circumstances. In fact, improving yourself is the only thing you have control on. So better get started on that.

---

Technorati tags: software development, career planning, languages

Writing Software Requirements for Developers

Writing requirements is difficult. Most, if not all, requirements documents are generally incomplete to varying degrees. When developers start coding, they realize that certain conditions are not addressed and get stuck. At this point, someone has to step in and fill the gaps.

Achieving 100% complete requirements is an impossible and highly expensive goal, not least because business needs keep changing. However, there is such a thing as inadequate requirements. When requirements are not enough, developers have to spend time to find the missing pieces. And if they resort to assumptions, the result is costly re-work.

One way for an analyst to create better quality requirements is to continuously think of what the developer would want to know. Requirements document what the customer wants to build. But unless the analyst anticipates questions that will arise during development and gets them answered, then such documents will keep developers on edge.

Let me elaborate upon this. Let us take any business entity in the application such as an employee or department record. Here are some of the questions that would need to be answered:

1. Operations: What can users do with this record - Add, View, Edit, Update & Delete? What are the restrictions on such operations? For example, the customer may not want users to delete employee records at all. A clerk cannot edit the Point-of-Sale information, but can only add a correction. A mechanic may want to do a "search" for an inventory part, but probably just see a list of car models.
   
   
2. Security: Who can perform each operation? For example, data entry operators can only do certain operations. Only certain managers can see aggregate reports. No one in the Chicago branch should be able to see the financial reports of the Houston branch and vice versa. A student could only see the names of other students in their class, but the school administrator can also see their Social Security Numbers.
   
   
3. Logging and Audit: Should the application track and record various operations with each record and the user who did the operation? Does the application need to maintain and compare different versions of the record? Should the application have the capability to turn off this audit capability when required? Should there be diagnostic capability to understand the health of the application with respect to data integrity and performance?
   
   
4. Dependencies: How does an operation on one entity affect the remainder of the application? For example, when a sale is made to a new customer, what other operations (such as future marketing) should be activated? Am I prevented from deleting an employee record if I have written some notes on that employee? Or should the notes be deleted automatically?
   
   
5. Locking and Concurrency:  Do multiple users need access to the same record at the same time? What kind of operations can they perform simultaneously? Do we need to prevent access in any way? Will that create any deadlocks? Will users lose data in this process? Thinking about such considerations is very important in applications having shared data.
   
   
6. Ownership and Sharing: Does each record belong to a particular user? Can that user share that information with other users? Can the other users edit that information? Can they share that information further with yet other people? Can a user prevent others from spamming him/her by sharing unnecessary information?
   
   
7. Workflow: What is the lifecycle of each record? For example, a document record may move from one user to another seeking approval. A bug may move from a tester to a developer asking for action and return back to the tester requesting closure. Who can act upon that record at each stage in its lifecycle? What are the possible next stages from each stage?
   
   
8. Data Formats: Can the user export the data to Excel, Word, CSV or some other format? Can they import it back from those formats? Does the application need to provide access to the data through API's or web services? Can power users directly interact with the data using reporting tools, bypassing the application and its controls?
   
   
9. Visual Formats: Do end users like a form style of data input or do they like a grid? What sort of colors and icons do they prefer? Do they like jam-packed, complex, powerful screens or they prefer simple layouts with large text and buttons? Are they keyboard-people or mouse-clickers? What usability, social and cultural issues do we need to consider?
   

You don't need to have all this information. It is likely that your application is much simpler and can eliminate many of these requirements. However, even the fact of stating that something is not a requirement makes it so much easier for developers.

Another reason I put up this long list is that many non-technical customers expect many of these features by default. They don't have the technical background to convey this information to you effectively. They may even miss telling you important security and workflow information, but expect you to know about it and ask them for it. After all, you are supposed to be the expert.

And if there is no single customer like when you are building products, you have to rely on market research, design standards and innovation to provide you information about these features.

---

Technorati tags: software development, requirements management, specifications, application features

When Everything is High Priority

Then nothing is high priority.

For this reason, it is very important to understand the difference between "severity" and "priority". At any point in time, there may be many severe issues. In fact, every issue you have may be severe. But you have to prioritize which you would handle first.

For instance, a building is on fire. Everything is burning - furniture, books, papers, computers, etc. And people are trapped inside. In terms of severity, every aspect of the situation is a severe crisis. But you have to prioritize saving the people first. Maybe next you need to save important data. And so on.

Prioritizing high severity tasks is a challenge. Many people get overwhelmed because there is so much to do and there are so few resources and so little time. And because of that, they decide not to do anything. And things get worse. People start running around like headless chickens.

A better way is to take one or two tasks out of the basket and start tackling them, while ignoring the rest. An example of where you could apply this is your professional learning. If you are working in the web development space, there are hundreds of topics you could learn in architecture, design, coding unit testing, etc. If you want to learn everything, you will not learn anything at all. Better to start somewhere and keep building on that knowledge.

It is also important as a manager to prioritize for others. For example, if when your tester finds critical defects in a module, it is important to establish what bugs should be fixed first, rather than marking everything as high priority. Also, the priorities for new tasks or bugs should be given by considering the existing tasks in hand.

And finally, watch out for things that have the potential to become high priority. Health issues are the most visible example. We neglect our health for years until the neglect catches up with us. Despite our claims to have "long-term vision", most of us are fighting the last war instead of preparing for the next one. If your planning starts today, the less number of severe issues you will have to contend with in the future.

---

Technorati tags: business management, prioritization, severity

What Day Should You Hold Meetings?

This is a follow-up from my previous post on the best times to hold meetings. But what are the best days to have meetings? Here are some thoughts based on my experiences:

• In my opinion, Mondays and Wednesdays are good days to have internal weekly meetings.
  
  
• On Monday, you can discuss the plan for the coming week and everybody can organize themselves to meet those goals. You can also understand what was accomplished or not in the previous week and make required adjustments.
  
  
• Wednesday can be used either as a primary weekly meeting or as support to the Monday weekly meeting. You can understand the progress for the week, see what is remaining and plan or work accordingly.
  
  
• Tuesdays are good for external meetings with customers. Customers usually don't have their internal meetings on Tuesdays and hence they can make time out for you. Mondays are too hectic for them to change their schedule or give you enough time. Fridays would seem like a good choice and is often preferred by people, but it has the defect explained in the next point.
  
  
• Fridays are bad for any meetings because people are less likely to follow up on any action items. On Friday, everyone is mentally shutting down in anticipation of the weekend (enjoyment or chores). While they may fully agree with you, their brain shuts down in the evening and your needs are forgotten. When Monday comes around, there are new issues to handle and you are nowhere in their thoughts.
  
  
• Thursdays and Fridays can, however, be used for meetings that are not directly related to project management and sales. For example, you could have training sessions, or formal code reviews on these days. You could also arrange meetings with other departmental groups that have a role to play in your project. A very long-term project could shift its regular weekly meeting to the later part of the week if it is less critical to the company's operations.

Of course, many companies have different practices that are best suited for their environment. One medical center I know had their staff meetings at Thursday noon time because that was when they had the least number of customers. Many companies have frequent meetings throughout the week. Agile Scrum methodology prescribes a daily stand-up meeting.

And finally, there are those who are in separate geographic locations and never "meet". They talk and exchange emails all the time. For them, there is less need for scheduled meetings.

---

Technorati tags: business management, meetings, collaboration

What Time Should You Have Meetings?

What is the best time to have meetings? Here are some thoughts about different times of the day.

1. Early morning meetings
   
   
   
   • Having a meeting as the first thing in the morning can be good if you just want to get it over with. This is ideal for short stand-up meetings or calls to understand whether things are going smoothly in the project. Once the meeting is completed, people do not have to worry about being distracted for the rest of the day.
   
   
   • Most people are usually full of energy in the morning. This makes for a more productive meeting with greater involvement and deeper understanding of the issues being discussed.
   
   
   • If different people start at different times in the day, it may not be possible to have such kind of a meeting. Some people will be rushing for the meeting while others have to interrupt what they are doing to join the meeting.
   
   
   • A longer meeting can be difficult for people who need to be able to respond to emails. Email communication, in my experience, tends to be heavy in the mornings and tapers off in the afternoon and evenings.
     
     


2. Late morning meetings that end in a lunch break
   
   
   
   • This allows people time to finish off important work they have to do before the meeting and prepare necessary presentations or updates for the meeting.
   
   
   • There is an incentive (food!) for people to not keep the meeting from dragging too long. However, people can stay on the discussion longer, if required, unlike an evening meeting where they usually have a hard stop.
   
   
   • This time is also good for customer meetings because you can invite them to lunch and continue your discussions informally. Great for establishing relationships.
   
   
   • However, if you have too many hungry people in your meeting, you may also see a lack of involvement and a tendency to simplify the discussion and make rash decisions.
   
   


3. Meetings after lunch
   
   
   
   • These are sometimes difficult to schedule properly, especially if you have to travel to get to the meeting. You may have to cut into your lunch hour to reach the meeting.
   
   
   • Most people are very agreeable when they have had a good lunch. They tend to listen longer to you and indulge you more. The downside is that they may be paying less attention to the specifics of what you are talking about.
   
   
   • Afternoon meetings usually tend to go on for longer durations since there are less factors pressuring one to end the meeting sooner.
   
   


4. Evening meetings
   
   
   
   • This is not a good time to have an internal meeting because most people are trying their best to wrap up their work and leave for home.
   
   
   • In the summer, people leave in the early afternoon. So this possibility may not even exist for you.
   
   
   • Some customers may like to have meetings at this time since it causes less conflict with their work.
   
   


5. Late evening meetings
   
   
   
   • This time may work for the senior managers in the organization, because most of the employees have already left for the day and they have the time to themselves to discuss key issues.
   
   
   • It also works for fragmented organizations, where employees work in different locations and can collaborate only outside the working hours of those locations.
   
   
   • The biggest problem is that it eats into the only time that senior managers have to themselves before they leave for their homes.
   
   

So it all depends on your organization, the meeting participants and what you are trying to accomplish. In my next post, I will talk about what days of the week you should hold meetings.

---

Technorati tags: business management, meetings, time management

GoToBilling - A Case Study

I recently got a chance to take a test drive of GoToBilling, an online application for business solutions. GoToBilling focuses on helping companies invoice and accept payments from their customers easily. They primarily serve small to mid-size customers. The application has other features such as marketing and CRM that aid in sales activities.

Though the product is not strictly related to project management and software development, I decided to write about it because I felt that it was an example of a good business application. For example, the application has the following features:

1. Intuitive Interface: The application has a very clean, well-designed user interface. Many business applications do badly on this. In 2000, I remember using the slow and torturous Verizon website to pay my bills, which I quickly abandoned. GoToBilling seems to have paid great attention to the layout and colors.
   
   


2. Attention to Flow: Layouts are great, but that would be useless if the application did not provide meaningful ways to accomplish tasks within the system. I liked the general use of dashboard and web parts. Some of the screens have useful buttons like "Save and Add More" which simplify data entry tasks. (I did get confused by their putting the Cancel button on the left instead of on the right.)
   
   


3. Focus on Business Need: They seem to have paid good attention to the 2 key modules - Payments and Invoicing in the application. Also the integration with QuickBooks is an integral part of any small business application. Personally, I have encountered the same need when building applications. Almost all business owners want to have data come out of your application and go into the accounting software, which is primarily QuickBooks.

The company's general website is an example of good marketing. It clearly explains the main modules in the application, who it is meant for, the general pricing scheme and support for developers. The application has a developer area where they have a forum and also developer tools for integration with their application. GoToBilling also has other services along with their product - Marketing, CRM and Gift Cards.

A few things that I feel that this company could improve upon: They only have videos in their Guided Tour, which makes it difficult for prospective customers to easily see all the functionality. It would be nice to also provide an alternative with several snapshots of the application. The company blog has very less content.

Overall, though, they have done a good job. What I have seen is that many small business owners are still in the desktop-application-driven (or even paper-driven) world and there is a great opportunity for companies like GoToBilling to grow and capitalize on this opportunity. A well-designed software catering to a well-defined audience.

---

Technorati tags: product review, gotobilling, features

Thinking

Here is an interesting quote by A. A. Milne that I found thought-provoking:

The third-rate mind is only happy when it is thinking with the majority.
The second-rate mind is only happy when it is thinking with the minority.
The first-rate mind is only happy when it is thinking.

There are different levels of thinking and learning. Here is a stab at what I think some of the stages are:

1. Not thinking at all or having no opinion.
2. Having an opinion or belief.
3. Knowing opinions contrary to one's own.
4. Learning to defend one's opinion against arguments.
5. Understanding the strong points of contrary opinions.
6. Accepting that the other party may have some valid points.
7. Formulating a new opinion by integrating strong points on both sides of the argument.
8. Playing devil's advocate against one's opinions.
9. Making opinions evolve through experience and knowledge.

Most of us are usually at steps 2 to 4. In many situations, this is perfectly fine because otherwise, we would waste unnecessary time and energy pursuing needless arguments. But there are other circumstances where not questioning what we believe and what we do can lead to inefficiencies and failures. An example would be the software processes that we follow every day.

Questioning our beliefs and actions is quite difficult. It is much easier to be for or against something and stay on auto-pilot. Sometimes, it requires external intervention from events and people to knock us out of our comfort zone and start critiquing ourselves.

One way to do this is to seek out contrary opinions. If you believe something, search for the opposite argument and read about it. For example, if you believe you should use Framework XYZ to write your new application, search on Google and find what the critics are saying. If you read about a new technique, learn about its weak points.

Above all, don't believe your own rhetoric. Tying your ego to your present ideas is a sure way to drown with them.

---

Technorati tags: learning, thinking

Software Evolution and Software Reusability

Software reusability has been the Holy Grail of the software industry. Managers and executives dream of the day when they can create software products by assembling software components like how houses and cars are built. Academicians have been predicting this for decades now. Still, we seem to be very far from such a state of reusability.

I don't wish to say that no software is ever reused or that software programming is always done from scratch. However, the bulk of software reuse has to be the use of functionality within the software framework that is being used, such as the operating system, the run-time environment or a framework for web applications. In effect, generic APIs are the most common software reuse seen to date.

But, even there, we don't see the "assembling" of software components to build products. The typical software development process involves a lot of custom coding. It is quite unlike having a lot of bricks and some cement to join them together. If anything, the process is more like having a few bricks and having to create the rest of the bricks.

One important factor is the rapid change in the fundamentals of building applications. Software environments keep improving very rapidly. Components built on older frameworks continuously face performance and software incompatibility problems. This is true at both the binary and source level. For example, a new operating system may not correctly support an older control's hardware calls. Sometimes, it is just cheaper to rewrite an existing control than modify it to work with the new environment.

New software environments bring new functionality that makes existing controls obsolete. For example, there were a lot of software vendors making controls for Active Server Pages. When Microsoft came out with ASP.NET, some of them (like File Upload) became less useful. On the Java side, especially by Apache, new frameworks and libraries come up that replace many of the functions that you or other software vendors may have written.

New languages make older code really obsolete. Newer languages like Ruby and Python keep attracting larger number of followers. If you are migrating to a new language, the libraries and code that you have written in an older language become obsolete. You may be able to salvage some code by using methods like translation, web services and binary inter-operability. But as you lose your competency in the older language, it is a waste of time to keep maintaining the old code to keep up with business requirements.

Existing languages keep getting better. It is not your older brother's C# or Java any more. Languages have been evolving at a much faster pace than ever before. It is almost like if you take a long vacation, the new language syntax can be incomprehensible once you come back. Backward compatibility does exist, but the new way of doing something is much easier and is better supported.

Supporting hardware and software keeps improving too. Today, desktop users have powerful multi-processor machines. Applications and controls could be re-written to take advantage of that. Database software also keeps improving in terms of new features for performance and ease of development. These are all areas where past code is probably not worth keeping around.

There have been revolutionary changes in computing paradigms. Recent developments and concepts like Ajax, RSS/Atom, mashups, cloud computing, etc. have changed the nature of software being developed. With Web 2.0, there has truly been an explosion in the number and quality of ideas about all aspects of software development including usability, performance, security, language design, etc. We are yet to sort this all out.

To conclude, I personally think that we are very far away from the assembly-line model of software development. There are too many fundamental revolutionary changes going on that it is very difficult to see that happen anytime soon. The only possibility of that happening is if software innovation stops happening, which is highly improbable.

---

Technorati tags: software reuse, software development, software evolution, changes

Managing for the First Time

We had an interesting discussion in our office today about how developers should handle new management responsibilities and reconcile that with their regular coding work. The topic was fascinating because there comes a time in the lives of many developers when they are no longer individual contributors, but also have to take responsibility for other people in the project.

The change itself may come about without much fanfare. But make no mistake - it causes significant disruption to the person's way of working and requires a different outlook altogether. Here are some of the challenges:

1. By definition, anyone who has been given management responsibilities over others will usually be more technically competent than them. When people make mistakes (as they inevitably do), the new manager is accountable for them, although she knows that she could have done a much better job if she had handled the task herself.
   
   
2. Good developers love coding and learning about new developments in software development. A developer-manager is too buried in tasks to spend large amounts of time on coding. He has to focus at a more higher level than get involved in the details.
   
   
3. They love being left alone to do their stuff. Managers, on the other hand, have a thousand interruptions a day. They have to interact with many different people. They seldom get time to focus on one task for significant chunks of time.
   
   
4. Managers have to interact with many kinds of personalities, including technically clueless people who are unaware of how software development works. This requires significant patience and understanding. Developers are used to being straightforward, not politically correct.

What is the solution? What should a person do? I think the first step in the process is to understand what managing is all about. Here is my definition:

When a person is tasked with managing, then managing becomes their primary responsibility regardless of their existing tasks and regardless of the actual hours they may be required to spend on managing.

Managing is not another task item on the To-Do list. It becomes the core function of that person. It does not matter what the title is: "module leader", "team leader" or "project manager". What else was being done by that person goes down in priority and managing should take precedence.

Managers cannot focus on their individual successes. They must do their best within their capability to help subordinates succeed. The manager wins or loses based on the performance of his/her team. Nothing else matters. There is no purpose in pointing to the manager's knowledge or work if the project is unsuccessful.

This is seldom understood by both people who give and who accept management responsibilities. Both think that management can be done "on the side" and pay a heavy price for the mistake. The people who appoint managers carelessly find that business objectives are not met. The people who are appointed managers struggle to understand why they are ineffective at their new jobs.

Understanding this basic principle leads to the manager re-inventing himself or herself. This consists of the following steps:

1. Understanding and committing to the business objectives: If personal objectives are in opposition to the business objectives, the manager must evaluate the situation and either quit the position or reconcile himself to the situation. Having one foot each in a different boat will not help.
   
   
2. Centering one's work around the business objectives: The management responsibility assumes precedence. One's own work has to be de-prioritized when compared to the task of helping the team succeed.
   
   
3. Delegating as much as possible: Most managers fail at this terribly. They keep holding to tasks they love doing and delegate what they hate. Instead, they should delegate whatever others can do better, take on tasks only they can do and continue training their team on handling even those tasks.
   
   
4. Letting go: The old life is not going to come back. The manager may have to deal with constant interruptions, incapable employees, tough superiors, rude customers, crazy hours, bad luck, etc. Being naive about what one is getting into can lead to supreme disappointment.

---

Technorati tags: business management, responsibilities, new manager

The Ultimate Present

The Complete Calvin and Hobbes Hardcover Box Set

---

Technorati tags: personal, calvin and hobbes

Bulgarian Translation

Mike Ramm has been kind enough to translate a few of my blog posts into Bulgarian and comment on them. Thanks, Mike!

• Hard-coding and soft-coding: English version here
• The Dilemma of the Capable: English version here
• When Murphy Strikes: English version here

Many of us, in our Anglo-centric view of the world, do not pay attention to other languages and cultures. But the principles of business management and software development are not restricted to people living in English-speaking countries. We must make the literature and knowledge accessible to all. People like Mike perform an important function here.

More importantly, there is much knowledge that we do not have, because we are not aware of the knowledge base in other cultures. Very few important works created in other countries get translated, if at all. As I have mentioned a few times before, the Communist regimes of Eastern Europe invested heavily in science and technology, but much of this knowledge is hidden in book shelves and the minds of students and professors.

If you look at the invention of programming languages, Ruby was invented in Japan, Python in the Netherlands, PHP in Greenland, and Pascal in Switzerland, none of which are English-speaking countries. There is much innovation and invention going on across the globe, but we are only partially aware of such happenings.

I believe that a fundamental next step of evolution of the Web should be in the direction of making all information accessible in each person's language. Search engines have a responsibility here of understanding queries written in one language and being able to retrieve related information in all languages. I know Google does fetch results from multiple languages, but I think it works only with proper nouns like Rio de Janeiro, Estonia, Claude, etc., not with common words.

Also when browsers display content in another language, they should be able to translate that automatically into the user's language of choice. Although this sounds hard, natural language parsers and translators are getting more intelligent and able to convey the right meaning. I have been using a plug-in for the Altavista Babel Fish translator (seen on the right), but in future, browsers may already come integrated with that functionality, instead of having separate buttons for translations.

As I write this, I did a search and found FoxLingo, a Firefox plug-in that seems to do a lot of this work.

---

Technorati tags: language translation, mike ramm, internationalization

This Book Changes Everything

Last week, I finished reading "The Halo Effect" by Phil Rosenzweig. In this book, the author explains how the "halo effect" or the tendency of people to attribute specific qualities based on a general impression can lead to false conclusions about what actually contributes to success in a business environment.

For example, if a company is doing well financially, people (both outsiders and employees) tend to provide high ratings for various attributes like great leadership, working environment, effective management and right strategy. On the other hand, if the company has a bad financial performance, all its critics jump on it and "find" that everything is wrong with the company.

This behavior is not restricted to companies. You can see it all the time in sports, entertainment and other fields. When a player or actor is successful, all the reporters and journalists rush to hype their every aspect. And the reverse is true when he or she has a failure.

We all exhibit the same behavior towards other people. When we like a person, we tend to glorify them in every respect. And when we are on bad terms with somebody, we believe the worst of them. This happens with people in our family, neighborhood, community and workplace. And no one is the exception to this.

The primary ramification of the Halo Effect is that it raises the possibility that we may be treating the effects of a business success or failure as causes for the business success or failure. For example, if people tend to think a successful company has good leadership, then good leadership is not the cause of the company's success. But rather, a successful company will be perceived to have good leadership - nothing more, nothing less.

The book also raises serious questions about the following 3 best-selling management books, each of which provides answers to what makes a company successful and great:

1. In Search of Excellence, by Tom Peters & Robert Waterman
2. Built to Last, by Jim Collins & Jerry Porras
3. Good to Great, by Jim Collins

Rosenzweig suggests that although each book (especially the last two) had considerable research (thousands of man hours of effort) behind them, they suffered from the Halo effect. The research was done after the fact, meaning after the successful companies had, in fact, succeeded. Hence, the successful companies would have good ratings for many aspects of their business. At the same time, comparison companies (who were not so successful) would be remembered in a less flattering light.

The various guidelines explained in these books are worthy of praise, as they do give managers an incentive and specific steps to improve their organizational culture. However, as Rozenzweig explains, none of the principles may have anything to do with contributing to the company's success. It could very well be that people's perceptions of the company improved as the company became more successful.

I can think of many reasons why this would be true. When a company is successful, it has greater stability and greater potential benefits in the future. Existing employees can see their prospects improving by continuing on with the company: greater financial benefits, challenging opportunities, career growth, better social status, etc. So do potential employees applying for a position at the company.

Employees are also more secure in their jobs thus avoiding financial worries. They can plan their lives better. Managers are under less pressure and stress and hence less liable to deal badly with employees. A successful company has more money to spend on things and activities that can keep employees happy, such as better infrastructure and tools, social functions, training, etc. A successful company can invest in more benefits for its employees. An unsuccessful company cannot do many of these things.

So, that is the key lesson from this book: Make your company successful and you will see improvements in various company performance factors. Trying to improve company perceptions without addressing financial success is a losing game.

---

Technorati tags: business management, phil rosenzweig, jim collins, halo effect

Bookswim - Book Lending Service

Bookswim, the new book lending service I signed up for, seems to be working very nicely. I received 3 books last week. They would have cost me around $50 at the very minimum. I finished and returned two of them. Now two more are on the way. At $20 per month, the cost savings is really good. And the shipping is free.

I also found the customer service very responsive. They replied back to all my emails and also pointed out an useful book request service. If you don't find a book in their inventory, you can submit a list of books that you want them to purchase. I submitted a big list of books and they added almost all of them, except a few pricey ones.

There were only 2 problems I faced. One was the slow performance in the initial days as many people hit the site because of the publicity. This situation has become better. The other problem which still exists is the search, which returns many unrelated results without proper ordering. Fortunately, the search allows ISBN searches, so it is only a minor hassle.

I definitely recommend signing up for this service if you like reading books (fiction or non-fiction, but especially the latter). And here is a list of some lists of books that other people recommend:

1. Personal MBA: http://personalmba.com/recommended-business-books/
2. Coding Horror: http://www.codinghorror.com/blog/archives/000020.html
3. Joel on Software: http://www.joelonsoftware.com/navLinks/fog0000000262.html
4. Steve McConnell: http://www.stevemcconnell.com/rl-cc.htm
5. Gray's Matter: http://graysmatter.codivation.com/HowIAmBecomingABetterDeveloperPart1OfInfinity.aspx

Also check your local library for some of these books, especially the business management ones. And that costs no money.

---

Technorati tags: reading, bookswim, books, recommended books

Mistakes in the Hiring Process

This is a follow-up to my previous post on hiring in which I discussed how hiring people is handicapped by the fact that very few of the eligible prospective employees actually respond to job postings. Let us discuss the actual hiring process itself and see what the pitfalls are.

First of all, a key thing is to understand is that you will make mistakes in the hiring process. You will, sooner or later, hire a wrong employee. But why do I state the obvious? Because many people assume that the end result of hiring will be the ideal candidate and that leads to several problems, such as

1. If you assume that you hired the ideal candidate, you will not spend time, effort and money on training that person and helping them succeed. You will expect them to hit the ground running. And when they fail, you will be disappointed.
   
   
2. When an organization places all its bets on the hiring process, people involved in the hiring process will not admit any mistakes even after the person is later proven to be not suitable. Thus incompetent employees are tolerated for much longer.
   
   
3. The hiring process can take much longer as candidate after candidate is rejected for some relatively minor deficiency that has little to do with their job function. Just so that the hiring can be "perfect", which it never will be.

Ego can also play a significant role here. Suppose you are hiring a Java developer. If you hire somebody who later turns out to be incapable, you may feel that it reflects badly on you, because you don't know enough about Java to ask good questions of an interviewee. Hence there is an incentive for you to remain silent and allow the problem to fester.

Back to the mistakes in hiring, here are a few of them:

1. Hiring based on capability, not on the fit: When you interview a person, typically you want to know what the person has done and what he or she is capable of. However, that is less important than how well the person will fit into your environment and blend into your team. I know many recruiters do ask about teamwork, but the point is not whether the person fit well into the previous environment, but whether they will into yours. 
   
   
2. Hiring in a hurry: When you desperately need a resource, you will take more shortcuts and make more mistakes in your hiring process. The fact is that it is already too late if you need a resource and you don't have anyone available. Typically, it could take anywhere between 2 weeks to 2 months to get a qualified employee on board, and even more depending on the seniority and experience.
   
   
3. Hiring over-qualified employees: Hiring under-qualified employees is too obvious a problem to mention, but hiring very senior resources for non-complex work is just as bad. These employees will not feel challenged by the opportunities you provide them and they will be quickly disillusioned. Secondly, this also means that your costs are too high and someone (investors, owners, etc.) is paying too much.
   
   
4. Not having the concerned manager do interviews: It may seem like a good idea to have a recruiting panel and then assign hired resources to different projects. However, if the concerned project manager does not have a say in interviewing the person, it can create many conflicts. Whenever possible, allow the project manager to pick the people he or she feels can do the project. A corollary is that if a person will not be working with a new hire, it is best to avoid them interviewing as they have no stake in a successful hire.
   
   
5. Ending the hiring process after the offer letter: You can only spend so much time and effort on hiring for a position. And for most ordinary positions, the typical candidate does not spend more than a few hours in total before given the offer letter. So neither the employer nor the new employee know much about each other. The next few months should be about learning about each other and see if it will work out. One difference when compared to the hiring process is that this step is not about filtering, but about helping the relationship succeed through training and opportunities.
    

The more experience you gain in hiring, the more you can avoid very obvious mistakes. However, even though the wrong people can get through because, in the end, you can truly know a person only once they have worked with you for a reasonable period of time. So don't rely on your knowledge of hiring to save you from mistakes.

---

Technorati tags: hiring, business management, interviews, recruiting mistakes

Agile Development and Requirements Management

Agile software development has emerged as one of the most popular software development methodologies in the recent past. Much of the rise has to do with the failings of other methodologies like the waterfall model and the bureaucracies present in implementations of prescribed methodologies like CMM. The principles of the Agile movement strive to match business needs with development realities and reduce waste as much as possible.

I have used Agile development practices in a few projects as well as observed how it is used practically in other projects. Using Agile concepts has served me well in many of these projects. Projects that involve continuous product development and enhancement benefit significantly from Agile project management, especially the Scrum model which allows time boxing of features within a specific "Sprint" cycle.

Unfortunately, the advocates and practitioners of Agile development has positioned Agile against other development methodologies, thus resulting in many cases of "throwing the baby out with the baby water". While Agile brings many useful ideas and strategies to software development, it has rejected many practices that have significant value in practical software development. In this article, let me focus on requirements management.

What does Agile say about requirements management?

Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Martin Fowler: "they (Agile methods) are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code."

The general view of Agile practitioners towards documentation seems to be:

• The program code is the primary source of understanding the system being built.
• Since requirements are continuously changing, requirements document will always be out of date, while the source code will be always up to date.
• So read the source code if you want to understand what the system does.
• Reduce documentation as much as possible to reduce unnecessary overhead.

While some Agile projects do maintain good documentation in the form of use cases and other artifacts, many Agile projects do not. Not because they cannot, but because they won't as a matter of principle. The way that work generally gets done despite this seems to be:

• Focus on test-driven development: Making sure that the application is tested against expected behavior using both automated tests in the form of unit tests (NUnit, JUnit, etc.) and integration tests (FIT). Continuous integration and daily builds are the norm in such development environments.
  
  
• More frequent communication: There is more heavy interaction between the team members. The daily scrum also helps raise any blocking issues that helps prevent developers from getting stuck in some module.
  
  
• Using wikis and other documentation: Here is where it gets interesting. Almost always, I have seen that Agile development ends up creating artifacts to explain requirements in the form of emails, Word documents (for specific functionality) or pages within a Wiki.

Some of the practices such as greater test coverage are commendable, but the others raise many questions:

• First of all, using source code as documentation creates many problems:
  • Source code is about the behavior of the system. Requirements is about the needs of the customer. The system behavior may not meet the customer needs. Where do we go to understand what the customer requested in the first place?
  • Source code can contain faulty implementation or buggy code, especially when it comes to nuances. Should that be treated as requirements?
  • 10 lines of requirements translates into more than 10 lines of code and that too, code not necessarily at one location. Should the developer hunt for such requirements throughout the source code?
• Instead of consolidating requirements into a centralized location, it is now dispersed into several other places and communicated through several different channels such as wiki pages, emails, chat sessions, bug tracking software, etc. and this happens over a period of time. As a result, no one really knows the entire requirements accurately. Even a full-time product manager cannot keep track of such changes consistently if the communication is so dispersed and undocumented.
• New project members take significant time to come up to speed. This is not as big of a problem at early stages of the project, but as the product grows bigger, this is a huge challenge. Apart from the lost time, there is greater risk of new project members misunderstanding requirements and introducing new defects.

One of the arguments given by Agile proponents is that Agile is meant for smaller, highly cohesive teams with motivated, talented individuals. Even if that is the case, you still hit limits of human biological capability when it comes to what can be stored and easily recalled in human memory. Even if you have been breathing the same module for months, you will still sometimes get stumped when you look at a piece of code and have no idea why you wrote it that way.

And then if a project is successful and needs to expand, it will need more developers to join the team. Even if they are highly talented, these developers still need enormous amounts of time to understand the system. In many cases, the existing developers need to reduce their programming time and spend it on training the new developers. Good documentation could reduce the time spent here.

Much of this heartache comes from a fundamental mistrust and fear of documentation. In a sense, some fear is justified because projects can get overwhelmed with documentation, but that is no justification to swing from one extreme to the other. Here is a possible middle way:

1. Spare a few minutes to customize a documentation template that works for you - easy to write, easy to read and easy to maintain.
2. There is no need to spend effort to collect 100% of the requirements before coding. However, collect enough requirements so that programmers can code without having to make design choices at the same time.
3. When new requirements surface because of new business needs or because of something that came up while coding or testing, incorporate that back into the requirements first.
4. Focus on making the requirements document the most accurate and up-to-date artifact of the project. If you have a dedicated product manager or requirements analyst, this task should be their responsibility.

A well-maintained requirements document does not hinder other good Agile practices. But still you will find significant opposition from Agile practitioners that maintaining requirements will take time and distract people from implementation. This is true, but only in the short-term. In the long run, the lack of coherent requirements and the resultant confusion and redundancy will eliminate and overrun any time or cost savings previously achieved.

---

Technorati tags: software development, agile methodology, requirements management