Mission: impossible. Stillborn projects

If you don’t know where you are going, any road will take you there.

LEWIS CARROLL, Alice in Wonderland

Introduction 

The vast majority of failed software projects, which I saw, failed before their start. Mission was impossible initially, because no one asked and answered nine simple, but important questions, which define concept of future project. The fate of such projects is abysmal. After investment of significant financial resources to development of something, investor seeing that it cannot even be completed, always tries to invest more and more money in the hope, that project will start successfully eventually and profit will exceed costs. However, only after consideration of conceptual definition of project, investor understand, that project has no chance to be completed successfully. Therefore, in order to stop loosing money, he stops development of project.

Below, we try to represent our vision of conceptual principles of projects and justify their importance. For illustration, we use project of expedition from book of famous Edinburgh University graduate – Robert Louis Stevenson (“Treasure Island”).

Nine points of the project concept

1. What for?

It can sound trivial, but every project must have its goals. Goals can be different: from earning million pound till increase of popularity of company. But, project need to have its goals. Otherwise, project looks as ship, which sails to unknown wharf.  Goals are criteria, which help us to define, whether our project move in the right direction at each time point.

What is the aim of expedition of search for treasures of Captain Flint? – Make a fortune.

2. What?

This question’s answer must define, what we need to do in order to achieve our goals. Which product or service must be the result of project and which characteristics must it have.

What? – Equipment of the ship “Hispaniola”; recruitment the team; sail from Bristol to Treasure Island; find buried treasure; return.

3. Why?

This part of concept must answer the question, why we assumed, that after realization of project, we will achieve our goals. Any action plan must built, originating from some suggestions and assumptions, which we must clearly define and analyze reliability

Why? – Because heroes of book are sure, that treasure is exist; no one found it; value of treasure is extremely high; map of Billy Bones is correct; ship and team are reliable; storm is not expected from February to September.

4. Who?

Who are participants of our project. Participants of our project are all concerned parties, individuals and organizations (for instance: customers, sponsors, performing organization, which actively involved into project). Each of concerned parties has its own explicit and hidden motives, which can impact on success of project.

In this case concerned parties are all heroes of book of Robert Louis Stevenson. The main ones: Squire John Trelawney – sponsor of project; Doctor David Livesey – manager of project; Captain Alexander Smollet – team leader; Jim Hawkins – system architect; John Silver – non-formal team leader; old team of Captain J. Flint – outsourcers. It is important to point out that all motives of above mentioned stakeholders, had significant impact on project.

5. How much?

In order to understand the costs of realization of project, we need to define and assess resources, needed for its creation.

Project expenses are: chartering of the ship “Hispaniola”, the purchase of purveyance and equipment, payment of team

6. When?

Fred Brooks mentioned in his book “Mythical man-month” that “The bearing of a child takes nine months, no matter how many women are assigned.”. He also mentioned some formulas, which can be very efficient in assessment of project time [For example: empirical formula of cost-optimum schedule time for first shipment: . This formula is efficient especially in conceptual planning stage.

7. Possible issues?

First, we need to know, that “Running away from risk is a no-win proposition” (Tom De Marco and Timothy Lister – “Waltzing with Bears: Managing Risk on Software Projects“). First, we need to assess validity of assumptions. In other words, risks are possible problems in project and project problems are the materialized risks.

Main risks of software projects:

  • Absence (incomplete information, frequent changes) of requirements
  • Absence of real communication with customer
  • Absence of needed resources and experience
  • Incomplete planning
  • Mistakes in assessment of human and financial resources of your project

The book of Stevenson might not exist, if his heroes analyzed main risks and their management plan at the beginning stage of the project.

8. Criteria of success?

Goals must be measureable and at the beginning stage of the project we must know, how we will detect success of our project.

Heroes must know, how they measure success of expedition. The goal is to earn 1000, 10 000 or maybe 1 000 000 pounds?

9. Who have profit?

Achievement of project’s goals must justify resources, used for its realization.

The value of buried treasure must cover all expenses of expedition and must give enough profit for team

Conclusion

Conception can consist of one or hundred pages. But it must be. Concept of project is the document, which can help us to detect right way during all time of realization of our project and gives us clear understanding of whether we will achieve our goals or not. As a rule, absence of concept testifies that project is deadborn.

Response to article: “Version Control: Important for Individual Projects?”

This is a response to the article “Version Control: Important for Individual Projects?”

Introduction

Version control is one of the most important tools used in software development process. The original article considers importance of revision control systems in projects, discussing which advantages of version control systems can be useful specifically in individual project with the same success as in team projects.
In this article, I will provide my vision to this problem, discussing ideas, presented by the author in original article and arguing points with which I agree or disagree, as well as will provide some additional information about useful VCS and related tools, basing on my own experience.

Advantages of VCS

I am strongly agree with advantages of version control systems, described by author in article. For instance, tracking of source code’s changes and their parameters (commit messages  time and information about user, who changed the code) as well as ability to revert changes – these are one of the undisputable advantages of any version control system tools for all type of projects and it explained and represented well in article. The possibility of sharing code, also mentioned by author as advantage for team projects, and I completely agree with their opinion. However, these characteristics is relate to repositories, but not to VCS, which is often integrated into different online repository systems.

Team and project sizes

I cannot be completely agree with the idea of consideration of necessity of usage of version control systems in projects in terms of the number of people in team, because VCS is system, based on idea of tracking the changes, made in documents (not necessarily source code documents), which means that it does more depend on the size of project than the number of members in project’s team.

As a person, who always work on his own projects, and have knowledge about different software development technologies, languages and tools, I always prefer to create all parts of my projects (maybe, instead of design) by myself. Therefore, my projects almost always large and I know a lot of other programmers with experience and interest to create complicated applications, who are also work on large projects individually. Therefore, I can state that there the size of team depends not only size of project. As good example, supporting this statement we can notice big projects, made by small teams or individuals. For instance, such big companies, like Whatsapp (which is very famous these days) with more than 500 000 000 customers base, consist of only 55 employees or Mojang AB company, which is famous for creation of popular game Minecraft with more than 40 000 000 customer base, has only 39 employees.

Another argument, which I write also based on my development experience , that one has never known at initial stage, how large will be their project, because there are a lot of large-scaled projects, which grown from small initial projects, made “just for fun”. Therefore, I am strongly convinced, that one need to start individual project with right set of scalable tools, which can stay actual and reliable, even if project starts to grow.

Disadvantages of VCS

Furthermore, in original article, author mentioned such problems connected with usage of version control system in projects as:

  •  when there are many people working on the same part of the code who want to commit both their changes with many conflicts in them and how to use the tool and setting up the system for version control.
  • learning the commands and functions to use the system can be hard.

I think this kind of problem can be discussed only in terms of specific VCS application or tool, because problems, mentioned by author are not general problems of VCS.

For example, branching and merging systems in distributed revision control systems can easily overcome first problem and there are large amount of easy-to-install applications, tools and plugins for IDE, which have GUI interface for VCS and can eliminate the need of usage of VCS commands, which are also not so much.

VCS tools

I support the idea of author to research the most useful VCS solutions for individual projects. Therefore, in order to make contribution to this research, I provide in my article some information about tools, used by me currently in my individual projects . As main VCS in all my projects, I use Git, because I prefer distributed revision control systems. As the main VCS client, I use Github client (free for download – www.github.com). I use Bitbucket and Github, which provide different types of repositories (public, private) within the free pricing plans for individual developers (free pricing plans are important especially for individual developers). Furthermore, I use Intellij IDEA as main IDE for development, which consists of good set of tools for VCS integrated into IDE, as well as free plugins, which provides wider function and support works with repository systems, mentioned above.

Conclusion

Summarizing all above mentioned, I want to point out, that I completely agree with author’s statements about advantages of revision control systems and that it is highly recommended to use.

However, I think that it is inefficient to generalize information about usage of VCS in the project, based only on the information about that whether this project is individual or the team project.

Why testing is not search of bugs?

Vast majority of testers are convinced, that testing of software product is a search of bugs. I am strongly convinced, that the main idea of testing process is to skip as less as possible bugs, than to find as much as possible bugs. At first glance, it seems, that there is not too much difference between these two ideas. But there is.

The testing process of large-scale software products is different from the same process for small software projects. Below I describe, what is the difference between two notions, mentioned above. Also, I share some good practices for testing of large-scale software projects.

What is the search of bugs?

What can be the main objective of testing in the case of search of bugs? Main objective is finding as much as possible bugs. And it is quite logical. For testers it is always good to find bugs, because bugs is visual representation of work done by them.

Which parts of software product will be tested in this case? First of all, the least stable parts of software will be tested. Frequently, these parts are less stable than other parts, because they less prioritize, but in this case it is not important, because the number of bugs is the main objective anyway.

What happens if there is bug, which cannot be easily reproduced? Reproducing of these bugs costs work time and it is better to find three bugs, which can be easier reproduced than current one, than spent huge amount of time, trying to reproduce the bug, even do not knowing whether it will be successful.

Which kind of tests will be done first? Certainly, the most non-standard, like division to zero, usage of different non-appropriate types of variable in certain fields, attempts to upload executable files instead of photo and etc. In the case of search of bugs, software testing process frequently starts not from testing of basic features of software, but attempts to find problematic moments in less standard part of software product, which can probably increase the number of founded bug.

I personally, cannot agree, that above-mentioned process has too much in common

with real testing of large-scale software product.

What is testing?

What is the main objective of testing? Main objective – skip as less as possible bugs, which are important for users. Less bugs are skipped, less customers complains – the more is the efficiency of testing process.

Which parts of software product will be tested in this case? In this case, testers will try to start with the most important parts and features of software for the end user. Even, if it is known that these parts are stable and worked successfully in previous release (for instance, in the case, when we have new release of existing software product, which has certain amount of new features, realized in it). Anyway, there can be problem with existing functionality, and in most of the cases, this functionality is not tested properly.

What happens if there is bug, which cannot be easily reproduced? If testers faced difficulties with reproducing certain bugs or misunderstanding of business-processes of end users or lack and technical requirements for project, it is important to research what is right and which way of is proper. In this case, testers can spend larger amount of time to reproduce and register bug in bug tracking system, but it will be more efficient, because it gives an understanding of architecture and details of software project to tester, which is very important in testing large-scale software products.

Which kind of tests will be done first? In this case basic functionality will be tested first. For example, testing of the most common case with standard parameters. And, only after completion of testing of basic features, new features must be tested. In my practice, I faced situations, in which after finding important bug in basic features, in the stage of problem solving, business-process was changed and hence, product is changed itself. In this case, testing of non-standard scenarios was not efficient and meant a loss of time.

Results of testing and search of bugs

If are considered the short period of time of testing and test of small software product, “search of bugs” approach can be efficient, because large number of bugs registered very fast.

However, if the project is large and testing process continuing long time, this approach is extremely non-efficient. Below are the proofs of this assumption:

•             The percentage of missed bugs increasing very fast, because of the lack of knowledge of architecture of the software project.

•             Developers try to understand the reasons of weird bugs which are appeared in very strange scenarios and which are very hard to reproduce.

•             In production version of software there are very simple but very important bugs, which are easily seen by users.

•             The amount of found bugs decrease dramatically.

How to change the approach?

In order to make testing of large-scale software projects will be efficient there are couple of simple rules, which must be followed during the whole testing process:

1.       Good analysis of product and documentation of tests

All test-cases must be fully-documented, which made information more shareable in terms of using together by specialists from different departments (such as business analysts, developer and etc.) as well as in terms of sharing knowledge with new and existing team members.

2.       Assessment of results and efficiency of testing process

Efficiency of testing must be considered and be measured during testing process. Also, the missed bugs and the reasons of missed bugs need to be discussed. Furthermore, obtaining data about other parameters, like coverage of functionality and code by tests and level of satisfaction of users also very important for large software projects.

3.       Discussion of objectives of testing with team

There is no single goal of testing appropriate for any type of software products. Each project has its own goals in testing and clear understanding of these objectives is vitally important for teams of testers. Therefore, discussion of objectives of testing in teams is very useful practice.

4.       Understanding of users and business-processes

There were software projects in my practice, when testers in team do not know too much about aims of products, its business model, end users, their environment and qualification. However, proper definition of all these parameters increases efficiency of testing and decreases probability of missed bugs. Understanding of business-processes of software gives opportunity for testers to understand the criticality of found bugs.

Summarizing all above-mentioned, I want to point out, that efficiency of testing of large-scale software products strictly depends on understanding the ideology of testing software and architecture of software tested.