Comments (0)

By Krishna, September 29, 2007

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.

Comments (0)

By Krishna, September 26, 2007

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.

Comments (2)

By Krishna, September 24, 2007

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.

Comments (0)

By Krishna, September 21, 2007

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.

Comments (1)

By Krishna, September 20, 2007

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.

Comments (0)

By Krishna, September 20, 2007

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.

Comments (3)

By Krishna, September 17, 2007

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.

Comments (2)

By Krishna, September 16, 2007

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.

Comments (3)

By Krishna, September 11, 2007

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.