How often have your heard one of the following phrases:

This is a small project so we will just have to put something together and FAST.

Big projects need to be designed in a totally different manner than small ones.

This is just a campaign product / prototype which is used only once. We can write tests later if the scope of the project is increased.

These phrases and many others like them suggest that big software projects require different approach than small ones. Even though this is partially true, each one of those phrases contains a hidden agenda:

First, they propose that small projects should be put together as fast as possible. Second, they propose that good software development practices such as unit testing, integration testing and code reviews are not as important in a small project than they are in a big one.

I have noticed that this attitude is surprisingly common but that does not make it right. I personally believe that this approach is flawed for the following reasons:

Not all projects start as big ones. In these cases the scope of the project is extended during the project. If you have separate practices for small and big projects, you will end up noticing that you have been following the wrong practices. This can be a critical mistake since you might have to go back to the code you have written earlier and adapt it to match the demands of the big projects This costs both time and money and your customer is often not willing to pay for it. And guess what? The customer is absolutely right. You made the mistake. You will have to pay the prize.

Small projects are important to your customer. It does not really matter whether the project is described to you as a temporary or as a permanent solution. The fact is that you cannot know if something you delivered is going to be a part of something bigger in the future. The only ethical thing to do is to ensure that you finish all projects by following good software development practices. This way it should be easier to extend the software you delivered if needed.

Remember that even if the project does not sound big and important project to you, it might be a huge investment to your customer and it should be treated as such. If you can ship the finished product with your name and contact details, you have most likely given the customer the respect he deserves.

Changing peoples attitude is hard. If your developers have learned that it is acceptable to cut corners in small projects, you are going to have a hard time to change their attitude when you finally get that big project you have been dying to get. The reason why this is hard is that you will have force your developers out of their comfort zones and people tend to resist changes like this. That is why the best thing you can do for your business is to follow good software development practices in every project. It will save both your nerves and your money.

Keeping your expectations high has also got a one additional benefit: It will make the recruitment process much easier for you. As long as you mention your high expectations during job interviews, it will be fairly easy to see who is not a good addition to your team.

I have now given you three reasons why you should treat each project in the same way. Remember that it is perfectly fine to decline projects which seem too small for you. However, if you decide take a project (either big or small), you should always follow the same principles and aim for delivering software which you can be proud of. If you are a real professional, anything less than this is simply unacceptable.

The problem with sprint retrospective meetings is that too often they are kept only because they are “required” by Scrum. If that is the case in your organization, you are probably feeling that sprint retrospective meetings are a waste of time. If I would be in your shoes, I would feel the same way.

I have written about sprint retrospective meetings before but after I read the book Implementing Lean Software Development – From Concept to Cash I realized that my advice was perhaps a bit too abstract. In reality, the solution for transforming useless meetings to productive ones is quite simple. All you have to do is to ask one simple question:

What is our biggest problem and what we are going to do about it?

There are two reasons why this simple question is such a powerful tool for identifying problems:

• It is concrete. If you ask concrete questions, you will get concrete answers. This means that the answers will identify the biggest problems which team members face in their every day work. Finding and solving these problems is important because it ensures that the members of your team can spend more of their valuable time for productive work. In other words, they can provide more value to the customer. Also, asking this question should protect you from hearing process specific mumbo jambo which does not identify the real problems or help you to solve them.
• It calls for action. Call for action is important because it reminds you that there is always room for improvement. It is very easy to fool yourself to believe that the status quo is as good as it is going to get (especially if you have been using agile software development methods for a while). Obviously, this is never the truth. However, as long as you keep asking that simple question, you will remind both yourself and your team members about one of most fundamental principles of agile software development: continuous improvement.

After you have identified your biggest problems and decided what to do about them, you must ensure that the problem are actually solved. I have written earlier that a good way to ensure this is to select a suitable team member who is responsible of solving the problem during the next sprint. The next question is:

How to select that team member?

I believe that a passion for a cause can help a person to achieve remarkable results. It is also very likely that the team member who pointed out a specific problem has a passionate attitude towards that problem. Therefore, in my opinion the best person for dealing with a specific problem is the one who pointed that problem out in the first place. He has the motivation and the knowledge needed to solve his problem. Let him use that motivation and let him feel proud of his work.

If you want to remember only one thing about this blog entry, it should be this:

If you let your team members to solve their own problems, you will get concrete solutions for concrete problems. On the other hand, if you decide to form a (management) committee to solve the problems of your team, you will end up with an abstract process description which is followed by no one. I don’t know about you, but I will take the first option any time.

I remember a time when I used to believe that the ability to create reusable components was a sign of a professional software engineer. This is definitely true if you are building a framework or a library. However, I am not convinced that reusability is valuable when a framework or a library is used for implementing an actual application.

In fact, I believe that in that case the reusability of software components is overrated, and in most cases the effort used to implement reusable components does not create any additional value. I argue that reusability is overrated because

• It does not add value to the customer. If the customer’s requirement can be fulfilled with a component that implements only a one function, the only thing that the customer cares about is that the needed function is working. For example, if the customer needs a component providing CRUD functions for a car, the customer does not care about the fact that the component can provide the same functions for airplanes or trains as well. And most importantly, the customer is not willing to pay for the extra work, which is needed to provide a generic CRUD component. And you know what? The customer is absolutely right.
• It adds waste to the source code. Creating reusable components requires more code than implementing a component, which has only the functions required by the customer. To make matters worse, it is more than likely that the additional code is never user for anything else. However, it still has to be maintained and tested every time when changes are made to the source code. This is more expensive and error prone than maintaining source code, which does not have unnecessary waste in it.
• If you do not know all the requirements, you have to guess. The requirements of a certain component covers only such use cases, which are relevant to the customer. Thus, if you implement a reusable component instead of a component fulfilling only the given requirements, you have to guess what the customer might need in the future. This dangerous for two reasons: First, you do not most likely have the needed information or expertise to make such decisions. Second, making a wrong assumption may prevent you from fulfilling the customer’s requirements in the future without making changes to the component’s source code. Therefore, it is a lot wiser to play it safe and implement only the required functions. Remember that it is a lot easier to extend a simple component after the requirements are clear than to fix a reusable component, which cannot be used to implement the new requirements.

I have now described you the reasons why I think that reusability is overrated when implementing applications, which are used to solve customer specific problems. However, I also realize that there are situations when the creation of a reusable component makes sense (even when creating customer specific applications). I just do not believe anymore that reusable components should be created just for the sake of reusability.

Since agile software development has really hit the mainstream during the last few years, it is only natural that there are a lot of misconceptions around. Also, I have noticed that some misconceptions are more common than other ones. This blog entry is written to introduce you the three most common misconceptions about agile software development, which I have encountered during my short journey in the world of agile methods. These misconceptions are:

Self-organizing agile team do not need to be managed

Even though it is true that agile methods do not include similar management than more traditional project models, it does not mean that no management at all is needed. Claiming so indicates that the person in question has misunderstood the role of a self-organizing team. In principle, self-organization is a quite simple concept. It means that after the team has committed to complete a set of tasks during a specified time frame, it can organize itself freely as long as it fulfills the goals, which were chosen by its members.

However, the team does not decide what kind of features are needed. This is where the management steps in. Its role is to provide a prioritized list of features to the team, which can commit to complete either all or some of them during a specified time frame. The management acts as a shepherd, who decides which direction its herd will move. The herd will decide how fast it can move to the desired direction. This separation of roles is required because it ensures that the team is doing the right things (or at least the things, which seem to be right at the moment).

Of course, if your team is full of domain experts who are using their psychic abilities to identify the right direction at all times, the separation of roles is not be needed. Unfortunately, you are never this lucky. In a normal situation discarding the role of the management can lead in to a disaster if the team cannot see the forest from the trees.

Agile software development means that no documentation is written

This is one the most common misconceptions about agile software development. However, the agile manifesto does not state that no documentation is written. It states that working software is valued over comprehensive documentation. The obvious question is: what is the difference? In traditional software projects a lot of effort is used to produce documents like requirement specifications, technical specifications and test plans. In fact, these documents are often required before the project can proceed to the next phase. Yet, the sad fact is that most of these documents are not updated or read after the project has been finished. The effort used to produce them has been futile.

Agile methods take an another approach to this problem. Agile projects aim to maximize the value delivered to the customer by producing only the minimum amount of documentation. This approach requires that the team can identify the documents, which are truly useful and valuable to the customer. Delivered documentation might include a short architecture specification, installation instructions and a documented source code. By producing only a portion of the documentation written during a traditional software project, an agile project team can use more time for implementing the required features.

One of the key principles of agile software development is to maximize the value delivered to the customer. If a document truly fulfills this goal, it should be written. Saying otherwise has got nothing do with agile methods, but it has got everything to do with misunderstanding your ultimate goal, which is to maximize the value delivered to the customer.

Doing agile by the book is the only way

If you have just started using agile methods, it is often safer to do it by the book. Just read a couple of books about agile methods or hire an agile coach to help you through the transition phase. This should help you to get started, but do not make the mistake of believing that you are now being agile; because you are not.

You should soon realize that there are aspects of this approach, which does not seem like a good fit for your organization. When this happens you should not be afraid to replace the malfunctioning parts with new ones, which suits better to your needs. Remember that continuous improvement is one of the corner stones of agile methods. As long as your goal is to improve the status quo, you cannot go badly wrong. Remember that if the things, which you are trying out, do not work, you can always try something else.

Doing agile methods by the book even though it is obvious that it does not work for you is not being agile. It only proves that you are still valuing processes and plans over individuals and change. Using agile methods is not easy. It is hard because there is not one right way to do it. In the end, agile methods are just a set of tools. You must decide how to use them.

I have now described you the three most common misconceptions about agile software development, which I have encountered during my career. However, these are not the only misconceptions around. It would be great to hear your insight about them.

I was trying to figure out a good definition of a domain model for this blog entry. All of my efforts led in to a somewhat clumsy explanation. However, I was able to find a good definition of a domain model from Wikipedia:

A domain model in problem solving and software engineering can be thought of as a conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain.

Sounds important or what? In other words, a domain model is an essential part of every application and it is a representation of real world concepts. But how can you distinguish a good domain model from bad one? The answer to that question is not obvious because understanding the domain model requires that you also understand the problem domain. My goal is to make this task a little easier by describing you the five characteristics of a good domain model.

A domain model is likely to be a good one if it

Models the problem domain correctly. A good domain model is not necessarily an exact copy from the real world, but it must model the problem domain with the required accuracy. This means that it must contain only the information, which is relevant for solving the given problem. Unnecessary information must be excluded from the domain model even if it would exist in the real world. However, containing the right entities is not enough. The associations of those entities must be correct as well. The problem is that before you can judge a domain model by using this criteria, you should have some knowledge from the problem domain.

Speaks the right language. Because a domain model is a representation of a problem domain, it is essential that its elements have been named correctly. This ensures that both the client and the subcontractor are speaking the same language. Speaking the same language is important because it minimizes the possibility of misunderstandings, which reduce the quality delivered to the customer. Verifying if the analyzed domain model fulfills this requirement is quite simple. If the elements of the domain model have been named correctly, your customer should be able to understand it without problems.

Claims ownership of its information. A good domain model controls the changes made to its information. This means that it should provide methods for manipulating its contents and prohibit all other changes to the information under its control. Providing only a single access point to the information of a domain model has two major advantages: it reduces duplicate code and protects the integrity of the domain model. Thus, following this guideline will lead in to cleaner and less error prone code, which should be the goal of every software engineer.

Also, if you need information, which is based solely to the domain model and has not other dependencies, you should place the method providing this information to the domain model. This approach follows the separation of concerns principle and it will improve the quality of your code by clarifying the architecture of your software.

Following these guidelines will also help you to avoid an anti pattern called Anemic Domain Model.

Provides built-in support for logging. Because it is often useful to write the contents of an object to a log message, a domain model should provide a simple way to obtain the contents of an entity as a string. This ensures that you do not have to construct log messages manually. All you need to do is to append the object in question to a log message and you are good to go.

Is covered by unit tests. This characteristic of a good domain model is kind of obvious (at least for professionals), but I have learned that assumptions can be dangerous. That is the reason why I wanted to write down a few words about unit testing a domain model. Even though I know that precise guidelines can be dangerous, I think that in this case it is possible to present an exact guideline for unit testing any domain model. You must simply test every method, which is not a getter or setter method.

I have now described you the five characteristics of a good domain model. I hope that this blog entry will help you to differentiate a good domain model from a bad one, and maybe give you some tips how you can transform a bad domain model to a good one.

PS. If you have design a domain model from the scratch, you might find this presentation about domain modeling useful. Also, I can recommend a book called Domain-Driven Design by Eric Evans. It is full of useful information about domain modeling and in my opinion it is a must read for every software developer.

When I am having trouble with a product or a service, I will contact customer support and expect that my problem is taken care of. Businesses, who truly care about their customers, ensures that the customer gets an answer right away or the customer support will contact the customer after they have figured out the answer.

Unfortunately, sometimes I notice that I am being bounced from person to person and no one seems to know the answer I am looking for. This kind of experience makes me really annoyed. In fact, it makes me want to scream. I am sure that you have had similar experience as well and you know how frustrating it is. This makes me wonder:

If every one of us knows how annoying it is to be in this situation, why so many agile software projects are suffering from the same problem?

The answer to my question is simple. Either a product owner has not been assigned to the project or the product owner is not committed to the project. Your current project is probably in this situation if

Team members must contact more than one person to get an answer to their product related questions. In this situation team members are spending their time figuring out how the software should work instead of implementing the wanted features. It should be clear to anyone that this lowers the productivity of the team.

Team members might also try to guess how the implemented software should work. This will probably decrease the productivity of the team, because their guesses cannot always be right and they have to implement some of the features twice.

A third problem is that this degrades the ownership of the product. In the worst case team members transfer the ownership of the product to a person, who is willing to answer their questions. This is (or at least it should be) considered as a serious problem, because the official product owner is responsible of the project’s outcome; The shadow product owner is not! Remember, ownership is not a floating point number. It is a boolean; You either have it or not (Thank you Russ Miles).

The priorities of the product backlog items are not clear. If the priorities are not clear, team members do not know which features they should implement first. This is a problem, because they have to either waste their time to find it out or use their own judgement when deciding what to do next.

The first case lowers the productivity of team, because the team members cannot figure out the priorities of the features and implement the features at the same time. The second case might lead in to a situation where “nice to have” features are implement before “must have” features, because team members are not often domain experts. That is why the product owner must communicate with the team and inform them which features are important and which are not.

Team gets no or very little feedback from their activities. Continuous improvement is one the most important principles of Agile software development. Constant feedback is an important tool for supporting continuous improvement, because it guides the future actions of the team. The project team cannot fix a problem if they are not aware that it exists. It is true that an active and motivated team can probably figure out some improvements, but those improvements are not probably related to the product in a any way. Also, it is quite important to understand that most of the people want to have some kind of feedback from their work. If no feedback is given, it might lower their motivation. This will probably decrease the productivity of the project team and decrease the number of improvements suggested by team members.

I have now described to you some of the characteristics and consequences of a situation, where the product owner of a software project is absent. The reasons of one’s absence are irrelevant. The fact is that each software project must have one (and only one) product owner. I admit that I do not have a definite answer to a question: how to be a good product owner, but I can tell to you what kind of product owner I would like to have.

I would like to have a product owner, who

1. Claims the ownership of the product and guides the team members to do the right things.
2. Ensures that the features of the product are implemented at the right order.
3. Motivates and guides the team members by giving them feedback (both good and bad) from their work

PS. Scrum Alliance has published a good article, which describes how one can be a good product owner. You might want to check it out as well.

I have been lately reading The Art of War by Sun Tzu during my buss ride to work. One Chapter of the book described the five faults, which may effect to a general. I realized instantly that the text could also be applied to software engineers. Without further introduction, I will give you the five faults of a software engineer:

There are five dangerous faults, which may effect to a software engineer:

1. Recklessness, which leads to destruction. If a software engineer is reckless, his quality of work will be considerable lower than the quality of work done by software engineers, who think before they act. Reckless people tend to make a lot of mistakes and some of them might be very expensive to fix. Even though a reckless software engineer would not make expensive mistakes, he will nevertheless spent his time to fix mistakes, which could have been easily avoided. Remember that it is almost always wise to think before you act.
2. Cowardice, which leads to capture. If a software engineer is desperate to stay in his old habits, there will be a day when he will notice that his skill set is simply not good enough. When that day comes, it is obviously very hard to fix the situation instantly. Even though the person in question could change his mindset and starts to study hard, the amount of absorbed information might be too much for him. The software development industry evolves very fast. Therefore, it is best to do yourself a favor and start studying today.
3. A hasty temper, which can be provoked by insults. Working with a short-tempered person can be quite challenging, because conflicts are a natural part of a work environment. It is unnatural to expect that each person would always agree on everything. This is especially untrue when it comes to software development, because the industry is known from sometimes fanatic arguments between people having different opinions. In this context the ability to have a civil argument and to receive criticism is indeed a valuable quality in a person, because it does not destroy the work atmosphere. Instead, it can have a very positive effect to it.
4. A delicacy of honor which is sensitive to shame. When a software engineer takes too much pride of his work (or feels very insecure about it), it often effects his ability to ask for help from his coworkers or a second opinion about his work. The main reason behind this behavior is that he doesn’t want to look incompetent in the eyes of his colleagues. However, the sad reality is that his attitude might actually make his fear become reality. Don’t be afraid of asking questions and remember to do your part by answering them.
5. Over-solicitude for his men, which exposes him to worry and trouble. It is great to love software development, but falling in love with a particular piece of code is troublesome, because objective approach is no longer possible. Objective approach towards one’s code is important, because source code is not really never complete. Nevertheless, a software developer must be able to recognize when it is good enough to be released. It does not really matter how good the code is, if you will never release it.

These are the five besetting sins of a software engineer, ruinous to the software development process.

When a career is unsuccessful and a software engineer feels unworthy, the cause will surely be found among these five dangerous faults. Let them be a subject of meditation.

PS. Those of you, who are interested of the topic, can also read the original text by Sun Tzu (Start from the 12th paragraph of Chapter 8).

The previous entry of my quality management series introduced quality management methods, which can be used during a software project to reduce or eliminate quality problems. Since this is the last part of that series, it is only just that I will describe a quality management method, which is used to verify that the delivered software fulfill the given requirements. The last stand of the quality management of software projects is called acceptance testing.

Acceptance testing has also got a juridical meaning. Typically project contracts state that a part of the price is paid after the software has passed acceptance testing. This practice is used as a carrot, which motivates the subcontractor to do its very best to fulfill its responsibilities. If the delivered software passes the acceptance testing phase, the customer of the software project has agreed that the subcontractor has fulfilled its responsibilities as agreed in the project contract. That is why this phase is very important to both parties.

It is often said that the goal of acceptance testing is to verify that the functions of the delivered software are working as the end users expect. This is a very important part of acceptance testing phase, but in some situations it simply is not enough. In these cases the acceptance of the software delivery might also depend on the outcome of

1. Performance testing. The goal of performance testing is to ensure that the performance of the system is acceptable. It is not obligatory to do performance testing in the acceptance testing phase. Actually it is often done by the subcontractor before the software is delivered. However, if the software has got strict performance requirements, it is a good practice to do performance testing in this phase.
2. Security testing. Security testing aims to verify that the delivered software does not contain security holes. The scope of the security testing depends from the type of the delivered software. A normal web application does not require so thorough security testing than for instance an internet banking application. Security testing does not have to performed during the acceptance testing. It is also a viable option to let the subcontractor to take care of it after the development phase of the application is over. In cases, where the application has got strict security requirements, it is often mandatory to do security testing in the acceptance testing phase.

The next question is how acceptance testing should be planned, and how the criteria for the acceptance of the software delivery should be selected. This process consists of following parts:

1. Specifying the test cases. The test cases are often derived from the requirements of the software. Thus, the requirement specification or other available requirement documentation is used as an input of the planning process. In an ideal situation test designers have not participated in the previous testing activities of the software, because participation in testing activities often leads into biased understanding concerning the scope of the needed testing.
2. Selecting the criteria for the acceptance of the delivery. This part is started by specifying severity levels for the possible findings. The principle is that the severity of each finding is specified by using these severity levels. Severity levels are used as a tool for deciding whether the software delivery can be accepted or not. It is a common practice to agree that only problems, which severity level exceeds a specified threshold level, can prevent the acceptance of the software delivery. Other problems are typically fixed later.
3. Creating an acceptance test plan. A test plan must be created for following reasons: 1) Without a test plan users of the software do not know what they should be testing. 2) It is only fair (and often required by the project contract) that the acceptance criteria is clear to the customer and to the subcontractor.

After the test plan has been created, it is time to start the actual testing phase. The most important practices concerning this phase are given in following:

• Functions of the software are usually tested by actual end users, who have got the best understanding of their needs. If the end users cannot be used, the second best option is to use persons, who have got previous experience from software testing. Usually, using developers of the software is a bad idea, because their participation to the project often prevents them from being objective.
• If security or performance testing is needed, they can be done by using customer’s technical personnel or external consultants. The selection between these options often depends on the schedule of the acceptance testing and the technical knowledge of the customer’s employees.
• The results of each performed test run must be entered to a test report, which must also contain the outcome of the test run (passed or failed).

After the criteria for the acceptance of the software delivery are met, the acceptance testing phase is officially ended. The delivered software is deployed in the production environment, and the subcontractor is paid. It is time to concentrate on new challenges and new projects.

Today I was asked, how the concerns mentioned in a sprint retrospective meetings can be transferred to concrete results. I am hardly a Scrum expert, but I have got some experience working as a member of a Scrum team. Thus, I decided to explain, what kind of methods I would use for obtaining maximum benefits from retrospective meetings. Those of you, who are not familiar with Scrum, might be curious to find out, what a sprint retrospective meeting really is. Glossary of Scrum Terms, which is maintained by the Scrum Alliance, defines the sprint retrospective meeting as follows:

The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.

At best, sprint retrospective meetings are a great tool for boosting continuous improvement, which in my opinion is one of most important principles of agile software development. However, in some cases the full potential of these meetings is not met. Team members might recognize what went well and point out some improvements for the next sprint. Even minutes of the meeting is written. Unfortunately they are forgotten right after the sprint retrospective meeting ends. Some improvements might even be taken to use, but this is often a result from the actions of an enthusiastic team member. It is probable that these improvements would have been taken into use anyway.

The obvious question is, what kind of methods can be used to maximize the benefits of sprint retrospective meetings? I will give you my five point checklist in following:

1. Ensure that everyone can speak freely. The definition given by Scrum Alliance states that product owner does not participate in retrospective meetings. In my opinion, product owner can participate in retrospective meetings, but if one decides to do so, one must understand that sprint retrospective meeting is not the place for advocating ones personal agenda. The goal of the retrospective meeting is to identify improvements for the next sprint. Some of those improvements might even be related to the actions of the product owner. If the product owner does not keep a low profile, some team members might prefer to keep their mouths shut, because they are afraid of the consequences.
2. Do not play the blame game. Do not use your energy for trying to figure out, who is guilty of making mistakes. There are two reasons, why this is a really bad habit. First, it does not help you to find a solution for the problem in hand. Second, blaming other team members will probably have a very negative effect to the team spirit and the motivation of the team member in question. You should concentrate on finding ways to improve the “performance” of the team, not lower it.
3. Do not allow vague statements. It is important that the team members describe their opinions as exactly as possible. Vague descriptions are not useful, because they do not identify, what the problem really is. If the team members are not able to fulfill this requirement, the ScrumMaster must ensure that the actual problem is found.
4. Transform identified improvements to concrete action points. After the improvements have been identified, it must be ensured that the suggested improvements will be done. First step of achieving this is to create concrete action points and assign them to an appropriate team member, who is responsible of finishing the task during the next sprint. This information must also be written down to the minutes of the meeting. Also, remember to create an issue to the used issue tracking system, and assign it to the selected team member. If this is not done, the improvement will probably be forgotten, because typically team members have got a lot of other things going on during the sprint.
5. Ensure that the action points are finished. Remember to follow up the issues created to the issue tracking system, and if necessary, encourage the team members to finish them. It is generally speaking wise to assume that the team members are motivated to solve problems, which improves the quality of their work or simply makes it easier. However, in some cases they might prefer working on tasks, which are related to the actual outcome of the sprint. In this case, they must be reminded that all issues, which are added to the sprint, must be finished before the end of the sprint.

I have now described you my five point checklist, which in my opinion will help you to make the sprint retrospective meeting more beneficial. As always, you should use your own consideration when applying these principles to practice. Every organization is different, and you should use only such methods, which works for you.

The first thing, which comes to mind, when someone is telling that he is working in the software development industry, is programming. Obviously, programmers have realized the same thing. However, programming is not the only job in the software development industry. It is not even the most important one. This blog entry is written to justify my opinion. So, if you are a programmer and you feel that you are the most important part of the machine, you should consider following arguments very carefully:

• Without sales, there is no need for programmers. This one is pretty obvious, but sometimes it is still forgotten. If there is no money coming in, there is no money going out either. This means that you are not getting paid. Thus, it might be wise to remember, where your paycheck is really coming from, because in the end, it is not your employer, who is paying your bills. I will give you a hint: If your product or service does not sell, you have to do something or end up filing for bankruptcy.
• Without specification, programmers have no idea what they should do. The key of making great software is to know, what you are expected to do. Thus, you should gather the requirements of the software, and create a specification, which you can use during the implementation phase. Remember that a specification does not necessarily have to be a huge Word document with 200 pages in it. The most important thing is that you know what you should provide, and the customer knows what to expect (Remember that every software project has got a customer. It can be internal or external, but it does exist!).
• Without project management, programmers cannot prioritize their actions. Without guidance programmers tend to focus on tasks, which are challenging, interesting or just plain fun. Unfortunately, since the task selection is a subjective process, the selected tasks might not be the ones, which would be most beneficial for the current project. This is where the project management steps in, and guides the programmers to the right direction by prioritizing the available tasks, which in theory should ensure that the most important features are implemented first (In reality… Well, that is an another story).
• Without testing, no one really knows, whether the software works or not. No one is going to pay for a software, which does not work. So, it is in your best interest to deliver a software that works. And yes, the only way to know, if a software really works, is to test it. A common misconception among programmers is that testing is easy and boring task, which does not require any special skills. That is why testers are not always getting the respect they deserve. Well, I have got news for all programmers out there: First, finding a good software tester is not an easy task. It is actually harder than finding a good programmer. Second, testing is not an easy or indifferent task. It is your last chance to impact to the user experience of the software. After the software has been released, you are too late. All you can do is hope that your QA department has done their job. Remember, you have got only one chance to make that crucial first impression.
• Without data migration from previous system, the new system can be useless. Sometimes having an old system replaced with a new one is justified, but that alone is not enough to make the new system useful. Users of the system are generally expecting that the information stored into the old system is available in the new version as well. Data migration can be tricky and demanding task, which is why it is usually done by integration specialists, who have got experience from transferring information between different systems and solving problems caused by different data models. Remember, if the information is not transferred, it does not really matter how brilliant the new system is. From the customer’s point of view, you have failed to deliver.

When all mentioned aspects of a software development work have been taken care of, programming is rather straightforward. However, it does not mean that it would be simple or easy. It is just straightforward. Oh, one more thing: saying that something is not the most important thing, does not mean that it does not matter at all. In the end, programming is just one piece of a gigantic puzzle. Without that piece the puzzle cannot be completed, but the puzzle has other, equally important parts as well.