Introduction

Open source softwares are programs that are released under certain licenses which provide source code of the program, allows the program to be modified and freely redistributed. Upon invention, open source softwares are most commonly regarded as charity work given by generous programmers who like to work hard and enjoy programming. When it comes to economy, people tend to have an ingrained believe that the source code of the software should be considered as top secrets and adopting Open Source Model will bring more difficulties for company to survive. However, this is not the case. For example, in 2008, Standish Group stated that by adopting the open-source model, around 60 billion are saved every year.[1] This article will introduces several perspectives that why everyone could gain benefits with open source software.

User’s view

To users, a program claimed to be open source software is promised with freedom on how the software is going to be used, where to use it and how long they are going to use it. Also there is no limitation about sharing the software with others. General speaking, users are quite happy with softwares with characteristics, such as freedom, and will be quite understandable even if the software could only satisfy their basic needs or there are some bugs existed. Furthermore, being able and willing to give the source code to public indicate the confident of the company or programmers have on their software that there won’t be any potential security risks such as hidden spying functions programmed in their software. Therefore, Open Source Softwares are welcomed not only by normal users but also organizations with huge concerns about security risks. Some might argue that open-source Softwares are less secure than proprietary software since it is easier to find bugs by studying the source code. It is true that the visibility of source code gives attackers more information to determine the weakness of the software. One the other hand, it also gives defenders same a mount of information on how to increases the security of the software. And unlike proprietary software, open-source software gives users or developers abilities to improve the security as they want without any limit. In this case, the security of the software is not only simply influenced by company, but also by the need of users and dedication of developers. We could believe that if the software is indeed useful for a certain mount of people. There should be more programmers stand up to defend for the software rather than destroying it.

Developer’s view

When developing open source software, programmers don’t need to worry about piracy since their software can be freely used and redistributed under same or compatible licenses. Similarly, with compatible licenses, a lot of time and efforts could be saved by reusing existed open source programs. Moreover, due to the visibility of source code, users of that software could be regarded as testers who is able and willing to provide detailed information. Furthermore, experienced users with programming skills could also provides certain amount of contributions through communities or online repositories.

With Open Source Model, individual developers are able to not only contribute to existed softwares but also realize their own ideas or even start a career. By writing an initial version and pushing it to online repository, other programmers with similar interests and skills might be able to give their contributions to enhance this project. One good example is the Linux Operating System which was created in 1991 by Torvalds Linus.[2] Upon creation, the only architecture it supports is 386 (486) AT clones and there were only two programs ported, bash and gcc.[2] Then, the adoption of open source software developing model gives Linux opportunity to grow continuously by receiving contributions from programmers around the world. After 20 years, in the year of 2013, for Linux Kernel only, there are more than 16 million lines of code.[3] Moreover, most of the servers are running Linux [3] and more than 95% of the worlds’ 500 fastest computers are running Linux[4]. With open source model, Linux has eventually grown from a personal interests to a large software which has a great influence around the world.

Company of view

By giving source code to public, company first build a good reputation to customers that they are confident with both the surface and what’s underneath their software. With adequate quality and free price, this software will be soon popular among the customers. Along with the increasing popularity, more and more new customers are willing to try it. Consequently, this open source software acts as an cheap or even free promotion for the company which could lead to bigger market share. Then, other services or products that works around this software will all be benefited.

When an proprietary software released, some customers need to accept that not all requirements can be met, not all platforms can be supported and not all features will be added in future development. In this situation, the customer service of this company will be in a hassle for answering different questions and demanding from customers. On the contrary, by providing the source code and a well written documentation, experienced programmers are able to implement their own modification, adding new features or porting the software into other platforms. With the help of online repository such as github or bitbucket, programmers could even work collaboratively as well as efficiently as a team which produces high quality codes with well documentations. Therefore, the company will not only benefits from their volunteering contribution but also will be inspired by new ideas which eventually makes the product better fits users’ needs.

In addition, the open source software has a strong vitality. Even if the software is no longer supported by its creator, other programmers could keep improving it. Due to this characteristic, once an open-source product is released, other business partners are able and more willing to make contributions to it since it won’t be suddenly withdrawn or outdated. One good example is Android Operating System from Google. Being released under Apache license enables Google and its hardware partners to work collaboratively which greatly increase the popularities of Android Operating System. In the third quarter of 2013, 81.3% of global smart-phone market share was taken by Android devices.[5] Moreover, a variety of different number of distributions, created by individual programmers or organizations, indeed satisfy different demanding of users and make the Android Operating System even more popular.

Conclusion

With Open Source Model, everybody benefits. Users are provided with softwares which have no restrictions on how they can be used, can be trusted with security and privacy concerns and promise to be developed for a long term. Developers can not only develop open source softwares, but also modifies and redistributed them without any worries of piracy. Moreover, by adopting Open Source Model, any new ideas could be quickly initiated and developed collaboratively. Companies providing open source softwares will have a better reputation, larger market share, better relationship with business partners. And the fact that volunteers are able to contribute results in huge amount of save in developing, testing and supporting the products.

References

[1] Rothwell, Richard (2008-08-05). "Creating wealth with free software". Free Software Magazine. Retrieved 2008-09-08.

[2] Torvalds, Linus Benedict (August 1991). "comp.os.minix". Retrieved 2009-09-06

[3] "Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It (2013 Edition)". Retrieved 2014-02-23.

[4] "TOP500 Supercomputer Sites: Operating system Family / Linux". Top500.org. Retrieved October 23, 2013.

[5] "Android tops 81 percent of smartphone market share in Q3". Retrieved 4 November 4, 2013.

Since the technology is continuously evolving and there is a great variety of software testing approaches that can be applied to different stages of the software development process, one would expect that failures related to software projects would have been limited and easily avoided. Numerous researches and statistics reveal that this fact is not true. Software project failures continue to occur. In some cases they do not seem to be significant, but in others they are quite serious and lead to the loss of huge amounts of money. Every year, there is a great list of companies that fail in the development of their products with reference to the investments that are lost in each case. All these examples have led to the creation of lists including the most common software failures, the most common reasons that cause their occurrence and finally tips and advice on how to reduce or even avoid the majority of them.

How is software failure defined and when is a software project considered as a failure?
A software failure occurs when a software system no longer complies with the specifications that were initially defined for it, which means that it does not present the expected behaviour and this situation can be externally observable. Bugs or faults in a software system tend to lead to errors (which occur within the bounds of a system and are therefore hard to observe) and then errors might cause failures. Faults, errors and failures follow a cyclic pattern in a software system. However, there are cases in which the error may be trapped and repaired by the system or it is of a particular type that does not give rise to a failure.

The definition of a software project as a failure varies and seems to be quite a subjective issue. Most of the times, it depends on the type of the project and the standards that the company producing it has set for it. A commercial project that exceeds the pre-estimated budget or does not meet the predefined deadline could be seen as a failure. On the other hand, an open-source project could be considered as a failure if it does not succeed in creating a community around it which takes care of its maintenance and evolution. Other reasons to define a project as a failure are related to the customers and their needs (e.g. the project does not satisfy the customers’ requirements), the team building the project (e.g. the members of the team fail to continue the work already done) and many other factors that will be discussed in a later section of this article.

Which are the most common causes of software project failure?
The issues that have been recorded so far as the reasons contributing to failures in software projects are various and can divided into two broad categories: technical and social. The technical issues are mostly related to the lack of up-to-date estimating techniques and to the fact that developers often fail to make a plan and encounter possible growth or changes in consumers’ requirements. On the other hand, social issues are associated with the attempt to adhere to a plan and some predefined deadlines regarding the construction of the software project resulting in lack of attention to detail and inaccurate results . [4]

A list with some of the most common software failure reasons is presented below [1], [2], [4]:

• Absence or bad definition of system requirements: The existence of Software Requirement Specifications (SRS) is fundamental in the software development process. System specifications that are not defined in a thorough and precise way can cause misunderstandings and lead to bad implementation. The accuracy of SRS is very important and can save much time and eliminate problems that could possibly arise during the next steps of the development procedure regarding the addition of new features or changes in already existing ones.

• Unrealistic expectations and project goals: There is a close relation among this factor and some others associated with the pressure caused by imminent deadlines and the skills of the software development team working on a project. In some cases, project managers fail to realise that it is not feasible to implement all the ideas regarding a project within the specified time limits, especially when some of them appear to be quite complex. Moreover, they often overestimate the abilities and skills of the members working on that project, who may be for instance young and inexperienced. The lack of a well organised plan based on the correlation among these issues can easily lead to project failure. It is also true that the unrealistic expectations can be a result of inexperience of project managers themselves.

• Absence or bad documentation: There are different types of documentation that are required during the various phases of the software development process. Adequate and up-to-date documentation is crucial as it helps developers think about some issues related to the project before actually starting implementing it and reduces the possibility of a failure.

• Poor communication among developers, customers and final users: There is no way of a software project being successful, if there is no constant and meaningful communication among these groups of people. Users’ needs and customers’ requirements and expectations change all the time and developers should always take into consideration this new information during the development process.

• Inadequate resources or use of inappropriate ones: Software development teams often tend to use resources and tools that are obsolete and as a result not the most suitable for the development of modern software projects. This can often cause unexpected and undesirable results and in the worst scenario to failure of the whole project. Software manufactures should be responsible for keeping themselves informed about the technology changes and being ready to exploit their advantages in order to improve their project. In some other cases, a bad estimate about the required resources may be done. This fact makes the development of software at the expected and predefined level extremely difficult and sometimes infeasible.

• Absence or bad risk management: Risks in software projects refer to uncertain states that could affect a project in an undesirable way, e.g. inadequate or badly written requirement specifications, use of unsuitable technology and tools, etc. Risk management is another crucial part of the software development process that should be precise, done from the beginning to the end and kept updated. In that way, many problems could be encountered and solved before becoming too serious and leading to failure.

Of course, a little bit of research and reading on very popular project failures that have been recorded during the last decades can reveal many more reasons that make software fail [5]. My intention in this article is just to give a brief list with some of the most commonly met.

Are there any precaution steps that could be followed to prevent software from failing?When things go wrong and people fail in achieving their goals, the lessons learnt during their attempt constitute the only positive and the most important part. Analysis of these lessons and feedback given either by small software development teams or larger companies leads to the creation of a list with some suggestions considered good enough to prevent failure and contribute to the success of a software project. Some of them are the following [3]:

• Careful consideration of user input and feedback during all the stages of the software development process

• Set of realistic goals and detailed plans and estimates about the cost and time that will be possibly required for the development of the software

• Choice of the right team by comparing the skills and knowledge of its members with what is needed for the right implementation of the project

• Constant update of documents related to requirement and risk management according to new users’ needs that may arise

• Provision of the right communication tools so that the communication between developers and consumers is never lost and is preserved during the development procedure

These and many other actions can help reduce the rate of software failure and somehow ensure the success of a project.

Many software manufacturers have been asked about their products’ failures and whether they have regrets trying hard or spending much time and money on them. It is noticeable that the majority of them mentions that they have no regrets and that it is worth taking some risks as they have learnt a lot from their mistakes and they have gained much knowledge and experience that could use in their future plans [5].

Conclusion
After explaining all the above, one reasonable question would be: since the reasons that contribute to software failures and ways of preventing them are known, why do software manufacturers tend to not apply them and leave their projects fail?

The answer is quite complicated. Apparently, the goal of every software development team is to produce a successful product. But, it is not always easy to take into account all these factors that can lead to a failure. Sometimes there is knowledge, but there is lack of experience on how to apply it correctly. In other cases, there is knowledge and experience but the time pressure imposed by deadlines or the limits on the available budget lead to compromises on the quality of the software produced [1].

It seems quite reasonable for software failures to continue to occur at some level, but the majority of them could have been avoided using the knowledge that already exists. The real challenge and the occurrence of true failures that have never happened before and for which there are no known methodologies on how to avoid them. In this context failures are somehow “desirable”, because only this kind of situations can help software manufacturers improve and make technical and economic progress [2].

I suppose that since there is much knowledge on how to produce successful software, it is time to take advantage of it and apply it in practice [2]. And even if a failure occurs, we should be ready to work on it and try to find possible solutions. But when is the right time to stop trying fixing a failure and cancel a project? Should we consider only the relation between the time and cost spent to it with the value that it actually returns? Or are there any other factors that should be also taken into account? In my opinion, this is one of the most difficult decisions that need to be made when software fails.

References
[1] Cohen Shwartz Oren, “Why Software Projects Tend to Fail “, September 2007
[2] Robert N. Charette, “Why Software Fails“, September 2005
[3] www.outsource2india.com, “Why do Software Projects fail?”
[4] Capers Jones, “Social and Technical Reasons for Software Project Failures“, June 2006
[5] successfulsoftware.net, “Lessons learned from 13 failed software products“, May 2010

Companies invest billions every to train and hire good managers, but is there something important that they are forgetting?

When we think of good managers we think of managers who help the company to success. In order to do this there are several skills they must excel in no matter what kind of group they are managing.

These skills include things like:

–          Communication and people skills

They must be able to understand directions and goals given to them from senior management and implement these within their team.  Within the team they must also be able to manage conflicts as well as being able to motivate and lead them.

–          Business management skills

Business management skills include things like thinking and implementing good strategies. Managers must also be able to make the correct decisions when presented with several options. Finance is also extremely important. Mangers have to be able to budget, manage cash flow etc. All of these skills are on top of managing actual projects within their groups.

 

The dilemma

All of these skills along with some others are of course essential for people to be good managers. But there is one skill I feel is missing – experience within the field.

Many people, companies and reports argue that experience within the field is not necessary. This may be the case for some areas of work but I feel it is essential for management of large software development projects.

There are several reasons people may be against this idea.  These include:

1. If a manager has been a software developer, he may want to get stuck into the projects. If this happens, other managerial tasks would be neglected due to lack of time and the business could suffer.
2. It is important that managers set projects that support the company’s overall goals. If an individual has been a developer previously they may pick up on errors and waste time fixing these even if they make no difference to the company’s overall goals and objectives.
3. Another strong argument is diversity. It has been proven that diversity of skills in a team can improve creativity, knowledge and productivity (Jehn & Bezrukova, 2004). Therefore a manager, who has no software development skills but other skills instead, would add to the diversity of a team and therefore increased productivity.
4. Managers are there to provide the team with the resources required to get a job done – not do the job.

 

I understand that these are all valuable arguments; however from personal experience in a software development team through an internship, the managers who had no programming skills let alone software development skills were not respected in the work place.

When the respect for managers was missing, team harmony was disrupted. Members of the team would get frustrated explaining what they were doing to the managers and the managers not understanding them. Furthermore in teams where the managers had no development skills, the time taken to complete a project was often underestimated. Missing deadlines meant teams could look like they were being very unproductive.  I feel that a manager who had software development skills would be a better judge of the time. They would also appreciate the effort it takes to complete projects.

When a team does not work harmoniously and team members are not motivated or happy to work, the whole company can suffer. It is estimated that companies spend billions every year (Amabile & Kramer, 2012) due to lack of productivity as a result of unhappiness at the workplace.

I strongly believe that the benefits of having a motivated, happy team outweigh the benefits mentioned above when a manager has no experience in the field. If a manager has had previous experience in the field they will not only be respected more by their colleagues but it will lead to a better understanding of the team and this in turn will allow a manager to utilize his workforce more effectively.

I understand that not all programmers and software developers necessarily have the skills to be good managers but surely in the 18.5 million software developers around the world (Ranger, 2013) there are some that have the necessary skills?

 

Bibliography

Amabile, T. & Kramer, S., 2012. Employee Happiness Matters More Than You Think, s.l.: Bloomberg businessweek.

Jehn, K. A. & Bezrukova, K., 2004. A field study of group diversity, workgroup context, and performance. Journal of Organizational Behaviour, 25(6), pp. 703-729.

Ranger, S., 2013. There are 18.5 million software developers in the world – but which country has the most?, s.l.: TechRepublic.

 

 

When you go to the shops and purchase a potato peeler, you receive the exact potato peeler that you picked up off the shelf. Five years down the line – if you have taken good care of your potato peeler – it will still work as well as it did on the day you purchased it. More importantly, however: it will still take the same form and have the same functionality as it did when you bought it (ignoring a few minor scratches, of course).

If one day when peeling potatoes you wished that your peeler could also be used to slice cheese into thin slices, you couldn’t simply take your peeler back to the shop in which you purchased it and ask the shopkeeper to exchange your old peeler for a newer model with all of the latest features. You could, however, buy the fancy new peeler outright if you so desired. It would be infeasible for the shopkeeper to keep on exchanging old items for new items in order to meet consumer demand, both in terms of practicality and – primarily – from a costing point of view.

The same line of thought can also be applied to large-scale software development projects. A survey conducted in 2010 – with contributions from over 2000 IT businesses both big and small – showed that the average software development company dedicated 55% of their annual budgets to performing maintenance tasks on pre-existing software solutions [1]. A second research survey suggested that the figure was more likely to be nearer two-thirds of a company’s budget – this is a massive figure [2]. While it appears that nobody knows for sure just how much the industry is spending on software maintenance, it is clear that the figure is steadily increasing as the years go by. It is my opinion that the budgets set-aside for the maintenance of existing software is too high, and could be significantly reduced if software development companies were less willing to bend to meet consumer demand.

It is well understood that there are forms of software maintenance which are unavoidable and – indeed – necessary: for example, bug fixes and the alteration of software to adhere to new or changing industry standards (e.g. a new memory management model being used as standard on new systems) [3]. However, there are concepts of the current understanding of ‘maintenance’ which I feel could be excluded from the process. The addition of new features to software is a common maintenance task. Whether it be a request and/or pressure from consumers to add to the existing software solution, or the development team actively choosing to augment the current solution, I feel that this sort of activity should not fall under the heading of ‘maintenance’ – but under another heading altogether. There has to come a point in the maintenance phase of the software’s lifecycle where the developer decides “enough is enough: the project has evolved into something too far-removed from the original concept.” When this point comes, the current time and effort being invested by developers can no longer be considered ‘maintenance work’, but another project entirely.

Returning to the example of the potato peeler outlined above: if you wanted to extend the functionality of your peeler, you wouldn’t be able to do it yourself (the average person couldn’t, anyway). The logical – and indeed, only – choice you would have would be to buy a new peeler which meets your new functionality requirements. The same concept should be applied to software. A development team will provide a company with the finished software solution to their outlined requirements and standards, and should from then on only perform routine maintenance to prune-out bugs and glitches. The addition of new features to the solution not outlined in the original requirements specification should be considered as ‘extensions’, and should constitute both a separate project and separate product. An example of this today would be downloadable content for video games: content which is not intended to be released as part of the initial solution, but can be purchased for an additional fee at a later date to extend the functionality of the original game. Using a solution such as paid software extensions could allow developers to shrink the size of their maintenance budgets, freeing up time and money to be reinvested in other projects the team is working on. Meanwhile, when creating additional content for software, costs of such an extension could be recouped in the charging of a fee to the client for the purchase of said content. Therefore, the maintenance budget has been reduced, and more revenue can be generated in the development of an ‘extension project’ for the client.

I can completely understand that, over time, the needs of a user can change. However, I feel that software developers should not be shackled to projects completed in the distant past. The solution delivered initially by the development team met the user’s needs at that given time: this should be the full extent of offering and implementing functionality to the project from the developer’s point of view. If the user needs the original solution to be moulded into another form, then they should have to fund this process – after all, you don’t see merchants of potato peelers handing out new models with sharper blades to existing customers when a new variety of tough-skinned potato is brought to market. If manufacturers of physical products don’t have to provide long-term maintenance, why should the developers of an intangible software solution have to?

The process of maintaining a large-scale software solution can be a very costly process. Over time, an initial solution can mutate into a completely unrecognisable form – nothing like its previous self. In my eyes, this should not be considered ‘maintenance’, but the development of a separate project. Maintenance budgets could be significantly reduced, and more revenue could be generated in the creation of functionality upgrades. The needs of a client can change over time, but it should not necessarily be the case that the development team should need to invest both their time and money in fulfilling such changes.

After all, if you aren’t happy with your potato peeler, buy a new one.

References:

1:
Technology budgets 2010: Maintenance gobbles up software spending; SMBs shun cloud | ZDNet. 2014. Technology budgets 2010: Maintenance gobbles up software spending; SMBs shun cloud | ZDNet. [ONLINE] Available at: http://www.zdnet.com/blog/btl/technology-budgets-2010-maintenance-gobbles-up-software-spending-smbs-shun-cloud/30873. [Accessed 14 March 2014].

2:
IT budgets to rise in 2013 despite downturn. 2014. IT budgets to rise in 2013 despite downturn. [ONLINE] Available at: http://www.computerweekly.com/news/2240174469/IT-budgets-to-rise-in-2013-despite-downturn. [Accessed 14 March 2014].

3:
Allan Clark. Software Architecture, Process, and Management (Slide 678). 2014. Software Architecture, Process, and Management. [ONLINE] Available at: http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/678. [Accessed 14 March 2014].

As the software industry continues its massive growth, we are witnessing an increasing number of graduate roles available, with positions such as “software engineer”, “application developer”, “<insert language here> developer” being a common sight on careers websites. Indeed, it’s the natural course of progression for most higher education graduates to head into a job, with around 91% obtaining employment within 6 months of graduation[1].

However, computer science graduates have among the lowest employment rates of any higher education subject area[2], which is entirely at odds with this expanding ‘IT’ industry. The reason? Employers don’t care for your first-class BSc Computer Science degree, nor your student BCS membership, or even that Natural Language Processing class you did on Coursera last summer.

The unfortunate reality is that simply holding a higher education does not qualify you for a job in large-scale development. In fact, structured education during employment – all those cutting-edge certifications you’ve achieved, or that professional accreditation hanging on your wall – aren’t what’s required. What it really takes is experience. And you can’t study that.

This article will examine the inadequacy (and unsuitability) of ‘recognisable’ education in the software industry, with a brief discussion of the use(lessness) of professional accreditation.

“Required: BSc Computer Science (or equivalent) at 2:1 or above”
More and more employers are requiring a minimum of a 2:1 degree from their candidates. Why? Because it’s become the de facto standard[3]. A candidate who holds a degree is not necessarily any better for a position than one without; they’re simply educated to a higher level. And employers know this: they’ve learned the hard way, but continue to ask for it nonetheless.

The reason a 2:1 isn’t enough is because of the shortcomings of a computer science-related degree. Great, you understand Gröbner bases of ideals of polynomials – but do you know how to deal with a colleague who’s insisting you’re wrong, against your better judgement? Oh, you can prove under what circumstances a binary relation is an observable bisimulation? Fantastic – but how would you go about developing a rapport with clients? Oh, you know Scala? Cool. We don’t use that here.

Whilst there’s something of a misalignment between the expectations of academics and employers, there’s also a problem of unclear degree titles. For example, I’m studying for a BSc in “Computer Science”, but my combination of course choices is entirely compatible with a “Software Engineering” degree. A vague notion exists that a Computer Science degree is more technical, mathematical, or even ‘harder’, but this needn’t be true.

And so with such uncertainties, employers are forced to look for other indicators of ability. I recently had a series of interviews with a large financial institution for a software developer position. They weren’t interested in hearing about my degree. They were interested in hearing about my work experience and, more importantly, my people experience. They were more enthusiastic about my part-time catering and retail jobs than they were about my studies. Technical competency was assessed, but I got the distinct impression that they weren’t worried about my (many) technical skills gaps: those will quickly be filled within a few weeks of working.

To be fair, some of the skills required of a competent software engineer are fundamentally unteachable – and it’s certainly not the responsibility of a lecturer to attempt to. But having completed nearly four years of a degree, I must confess that, personally, I don’t feel well-equipped to enter the world of development. At least, not from a technical perspective. It’s all very well teaching the theory and advantages of various practical systems, but failing to provide a platform to try them out makes that knowledge pretty useless.

What compounds the problem, of course, is that the academics who are designing and delivering these courses often haven’t worked in industry for some time. They have grown in their own community, with its own set of (ahem, abstract) expectations. These expectations don’t exactly intersect with the needs of modern software houses, and instead of encouraging group projects and collaborative work between students, it’s a constant barrage of exercises for exercises’ sake.

And so employers are having to take their own measures to fill those skills gaps in their newfound employees.

Education continues into employment
One such measure is the use of accreditation. At the individual level, accreditation is “a form of qualified status … awarded by a professional or regulatory body that confirms an individual as fit to practise”[4]. Before you can be awarded an accredited title, you must have gained a minimum number of years’ relevant experience, as well as pass several exams. Unlike degrees, however, software houses seem to love accredited individuals: the ‘Chartered’ label is something of a status symbol, which they can use to lure new clients. In an earlier blog post, I wrote about how organisations often misuse such information to their advantage – this is a classic case here.

Interestingly, however, software developers seem to love it too: it affords them the opportunity of fast career progression. Often developers will be proactive about seeking out accreditation for themselves, since it will open the door to promotions and, ergo, pay rises. The ironic thing, however, is that the natural course of a software developer’s career in large organisations is the move from being a developer, through to making long-term design and architectural decisions, before finding yourself plonked in the management seat, directing a team and its budget, and not doing any implementation work yourself. This makes it harder for you to remain ‘current’, especially in such a fast-paced industry. The use of accreditation, then, serves only to push a developer into a particular career track, and not to benefit the software projects they’re working on.

Accreditation in an immature discipline is fundamentally valueless
Let’s take a moment to look further into accreditation in the software industry. Some careers require registration and accreditation from a professional body – for example, an architect operating in the UK must be registered with the Architects Registration Board, and only a Chartered Accountant is allowed to audit the accounts of public companies [5]. But this isn’t the case for a software engineer. In fact, receiving accreditation from, say, the British Computer Society (“The Chartered Institute for IT”), doesn’t qualify one to do anything more than they could have done previously.

This prompts us to think, why? Architects have to design a safe and structurally sound building. Chartered Accountants are reporting on the finances (read: honesty) of companies in which a huge number of people have a financial stake. Other registered professions – doctors, dentists, lawyers, for example – all have a duty to the public. And we might argue that software engineers should, too. A flight control system, or the software backing a nuclear reactor, or your electronic summary care record – these systems are all ‘critical’, but don’t (legally) require a professional graded ‘engineer’ to develop them. This, I propose, comes down to the fact that software engineering is far too immature a discipline to support professional body accreditation.

Perhaps this problem is rooted in the idea that, despite unrelenting advancements in the software industry, it’s rare to find a universally-agreed “best approach” to a given problem. All we can do is depend upon the experience of long-term developers, and hope that the knowledge they’ve gained over the years is enough to get us through. No amount of PhDs or MInfs will save you now.

Do we need formal education at all?
Oh, yes. When else in your lifetime will you get 5-month-long summer holidays?

Ultimately, it boils down to this: university education doesn’t make you a better programmer; it doesn’t make you a better team player; and it doesn’t teach you the core skills you need to nail that job. What really matters is experience: the longer you work, the wiser you’ll become.

And no matter how hard you try, you can’t study ‘work experience’. You actually have to experience it for yourself.

Continue reading “BSc Computer Science, huh? Who cares.”

Introduction

Most software projects fail.

According to the Standish group, the software project development failure rate has been around 70% over the course of the last 20 years. This is a staggering statistic. There is no simple solution to ensure software development success, but a lot can be done to mitigate the failure rate.

Most software projects are not the public web services we use everyday, and not shrink-wrapped software. Many of the projects that fail are custom software projects built for governments and corporations. The teams involved in these projects usually have little to no exposure to the Silicon Valley technology startup scene. Some of the greatest software successes have come out of the Silicon Valley, and I believe a lot of the problems that software projects encounter can be solved by following strategies that have become common-place in the Bay Area.

In 2011, Eric Ries, a Silicon Valley entrepreneur published a book called “The Lean Startup”, describing a methodology for building businesses and products. Although there is no silver bullet, I believe that following this methodology can mitigate most important aspects of development failure and increase the success rate of all software projects, even when they have nothing to do with startups.

Solving Problems with Lean Methods

One of the most common problems in failing software projects is the lack of clear requirements and specifications. This is a problem startups face as well. It is often uncertain whether the market wants the product that the startup is building or whether the project will ultimately turn out to be unsuccessful. The lean startup methodology suggests using the MVP (Minimum Viable Product) strategy to first test the market. A simple mock product is built with a very limited set of features, satisfying only the most important requirements, and shown to early adopters. Feedback is collected, and the potential of the product is then evaluated. Similarly, when the specifications are unclear for software projects, building a product akin to the MVP can be helpful in collecting early feedback from the clients, and then using the feedback to clarify the specifications.

Another common problem causing software project failure is the lack of project status updates. Clients cannot easily find out how much progress the development team is making. This is because it often takes a long time before developers can show the first version of the project in a usable state to the client. Ideally developers should build upon the MVP, continuously improving the product and collecting feedback from the client. The lean method recommends that startups implement continuous deployment to achieve this, immediately releasing a new version whenever any small change is made. In that way, any issues encountered by the client can then be taken into account as soon as they are noticed, rather than after the project is deemed finished.

Continuous deployment also allows the client to see how fast the project is developing. By measuring the pace of development, and taking note of which features still need to be implemented, it becomes easier to set a realistic estimate for the project. Obviously this does not completely solve the problem, but any estimation method is better than pulling the deadline out of thin air.

The project requirements may be unclear, but if a software development team has a way to continuously collect feedback from the client, based on it, the team can decide whether to pivot or persevere. As in, decide whether major changes need to be made to the ‘MVP’, or whether it is fine to develop the project further in the same direction. As long as the feedback from the client is taken into account, to some extent this shields the development team from the politics involved in project planning and management: every change is being made in order to satisfy the client. Rather than following some manager’s guidance on what feature to implement next, developers can decide on that simply by looking at the feedback: figuring out what clients complain about the most, what bugs they find the most annoying, and what features they demand the most.

Other common reasons for project failures are poor project management and sloppy development practices. If the management team is incompetent, there is not much developers can do about that, but at least when it comes to development practices, a lean methodology forces the development team to adopt agile development techniques. Surveys have shown that the usage of agile methods usually results in better software quality and productivity gains, hence, improving the chance of success for the project.

Conclusion

Clearly the lean startup method is much more general than you would expect it to be, and it can also be applied to non-startup projects. The methodology is proven to work, as many successful companies such as DropBox and Intuit were built upon it. The methodology ensures that the pace of development is fast and that client’s feedback is taken into account from the very beginning of the project. There is hope that as time passes more and more software teams will become aware of the lean method, and that many software project failures will be avoided by adopting it.

Crowdfunding has expanded in recent years to scales unimagined before. Recently Kickstarter – currently the largest crowd-sourcing platform, announced that over 5.7 million people have pledged North of 1 Billion US Dollars to campaigns promoted via the website.

Although the success stories of projects realised via the collective effort of the crowd have altered several industries, particularly game development and publishing, crowdfunding has arguably reached a saturation point, where the bars have been raised so high and competition has become so fierce, that chances for success of smaller projects are falling by the hour.

One field that is enjoying increasing attention in the crowdfunding world is the production of open source software and hardware. At first glance the two seem like a perfect match, after all crowd-sourcing originated as a way for creators to gather the required resources for projects that would benefit communities they were part of. However, with the rising of campaign targets and project quality, the altruistic side of crowd-funded open source development is giving way to the business models governing the field. Creators are investing increasing amounts in advertising and other side-costs, while ‘open source’ is becoming nothing more than a buzzword for attracting a specific target audience and selling it a plain old consumer product.

The decay of truly independent small-scale campaigns

Changing  standards

Take a quick glimpse at Kickstarter’s homepage and you will notice immediately the beautiful photos and cover arts of the featured campaigns – the top crowdfunding efforts handpicked by the website’s staff. Projects that have often taken months to envision and plan, crafted with attention by professionals and properly backed-up by extensive research.

Now compare this to what Linus Torvalds shares to his fellow Usenet users prior to releasing the source-code of Linux – probably the most famous open source software today:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready.

… It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.”

—Linus Torvalds

One of the core values of open source appears extinct on the front-page of Kickstarter – the joy of the discovery and creation of an elegant solution with no other incentive than satisfying your curiosity or reacting to the frustration created by some exiting product.

Hidden costs

At the Wikipedia article about crowdfunding there is not a single mention of the word ‘costs’ or any explanation of the potential overheads in creating a successfully funded campaign.

My recent experience in helping one of my friends in creating his Kickstarter campaign that, at the time of writing, is halfway through its 30 days of funding, shows that 5 months of careful engineering and considerable investments, 2 days of video shooting with an expensive DSLR camera and numerous revisions of campaign marketing material may not be quite enough to make it. He decided recently to invest further in advertising, as none of the technology blogs he had contacted were willing to publish the news about his gadget before accepting a generous fee for the service.

Not to mention the 10% subtracted from the total earnings in order to aid the noble cause undertaken by Kickstarter’s staff.

To put this in an easier to understand form for computer scientists:

Crowdfunding == Business;

Surprisingly low success rates

Last but not least, let’s consider the entrance barrier for the club of the successfully backed crowdfuned projects. This sutdy on the topic states that three quarters of the gaming crowdfunding campaigns fail to meet their backing target, while recently just 7.5% percent of open source projects have been successful.

Last time I checked the success rate of my GitHub open source projects, it was close to 100% with the staggering number of active contributors of 1. A humble victory, but a victory anyway, compared to a dead Kickstarter project.

The problem with large crowdfunding initiatives

Ghost Blogging

Ghost is a NodeJs based blogging platform envisioned by John O’Nolan, a former WordPress (a.k.a. the open source blogging platform) developer, that aims to get blog writing back to its basics –  that is: beautiful typefaces, contemporary design and Markdown editors.

Naturally the platform is intended for the free speakers by being completely open source, with the tiny note that the backers’ funds contribute towards a hosted service that will provide Ghost in all of its beauty for a tiny annual fee alongside the development of the open source project.

In my humble opinion – this is called business, not open-sourcing.

Fast-forward 9 months after the successful funding of Ghost Blogging, exceeding the target by nearly 800% and the HEAD branch of the GitHub repository of ghost has version 0.4.

Fast-forward 9 months after the successful funding of Ghost Blogging, exceeding the target by nearly 800% and the HEAD branch of the GitHub repository of ghost has version 0.4.

During a recent attempt to develop a simple Ghost theme that separates blog posts based on their tag (no categories as of yet) in two content pages: posts and gallery, I discovered that the Handlebars template engine behind Ghost supports only built-in functions such as post.title() and post.content(). In other words the simplest possible extension of the system would require changes in core and trashing simple upgradeability of my web site forever.

In the meantime John O’Nollan’s team has been busy rebranding the Ghost Platform-as-a-Service and advertising it’s growing features.

As I may have previously mentioned:

Crowdfunding == Business;

DigiX

Since at this point one could easily accuse me of ranting against the single black sheep of the flock, let me tell you the similar story of a hardware open source project I recently backed and received in my mailbox a month ago – Digix – “The ultimate 100% Arduino Due compatible dev board with Wifi and Mesh networking, Audio, USB OTG, microSD, and 99 i/o pins!“ Did I mention that “[t]he DigiX – like everything we produce at Digistump, is Open Source Hardware.”?

My initial excitement after unpacking the beautiful piece of hardware and plugging it in my PC was quickly suppressed after discovering how poor the documentation for the device was. I quickly realised I was sold a fairly expensive device that was advertised as the better alternative to the widely popular Arduino which – you guessed it right, is properly open source and funded by the sales of a truly original hardware platform that has been tested and improved by many and has proven itself as an excellent product worth its price. Yet my new toy was no match to Arduino in terms of support, documentation, lack of bugs and active development effort.

Alternative? (for a lack of better conclusion)

At this point you might be wondering whether I am not defending the view that developers of open source hardware and software don’t deserve to be awarded for their hard work. Or perhaps I dream of some romantic ideal of open source, where every effort is fully rewarded by simply earning the community’s recognition and respect.

This is certainly not the case when we talk about genuinely innovative initiatives that have expanded to become commercial products, but in their core continue to support the independent creators on budget by giving full power without hidden costs.

I believe that the preceding chapters have made my point about the difference between those and crowdfunded projects quite clear.

Introduction

Nowadays, a variety of different platforms exist in web, mobile, and desktop forms and have a fast increasing user base. As a result, it has become common practice to design portable systems that can be reused in other platforms with a minimum number of modifications. While recently discussing with a developer of a well known Windows Phone app, I was told that he also uses this practice so that he is able to port his app to other platforms, as it costs a lot to build it from the ground up for each platform. However, when software that is native to a platform is ported to other platforms, of different capabilities and requirements, users end up with an inferior product (eg. Flash for OS X). To my point of view this policy is greedy and ultimately a bad practice. I will give evidence of how device-centric, native applications are of higher quality and attract more users as a result. 

Background

For the purposes of this article, when referring to platforms my focus is on mobile operating systems, for two reasons. The first is that mobile applications have recently become extremely popular, thus profitable, and have attracted the interest of many major software companies. The second reason, is that each of the major mobile platforms is fundamentally different to the rest and comes with their own set of native tools, programming languages and UI style.

These two factors can result in a recipe for disaster, a fact that has been proven multiple times even by large software companies. Consider, for example, an app natively developed for iOS and after becoming successful a decision is made to port is to Android, Windows Phone, a Web version etc. Most of us have seen this happen many times as users and it rarely has any success. The ported version of such an application will often have worse performance than its native counterpart, more limited functionality and a UI that feels out of place, all of which frustrate end users. Users, in turn, will not give a second chance to an app that does not satisfy them as long as there is an alternative, and in a world of mobile platforms with millions of applications there will most likely be a better alternative.

What makes a native application superior?

While it is expensive to have an application built from the ground up for each new platform, there are certain advantages [2] to native applications that the users appreciate. Firstly, native applications can be designed to leverage platform-specific hardware and software [3]. They are able to use all the specific APIs of each platform and work well with the integrated apps of an operating system, such as camera, adress book etc. Additionally, being written in the platform’s native language they can exploit the capabilities offered by it, offer increased security [5] and work around its limitations resulting in better performance. Secondly, each of the modern mobile platforms has certain guidelines [4] for the UI design and other aspects of development, to make sure that usability, appearance and feel of each app is on the same standard as all other native apps. Users have come to expect applications -free or not- to be of such high quality, hence it is imperative to their success that native applications follow these guidelines.

In addition to the above, I trust that the best possible practice is for an application to not just be designed in a platform-centric way, but even more specifically in a device-centric way [7]. Meaning that there should be different versions of the app, for the same platform, depending on the specific device it is going to be used on. This is because even though two devices may technically share the same platform, physical characteristics of a device may set it completely apart. Users for example have more expectations of what a tablet app should be like, both in UI and usability, rather than a mobile app. Mobile apps that have just a scaled UI to fit the bigger screen as their only difference from their mobile version are being badly received by users. Despite this fact, even well known companies, with millions of users, tend to overlook this fact and in return receive poor ratings or lose users [6].

 Conclusion

It is attractive and easy to port a mobile application across different platforms but just because it is so does not mean it is beneficial. On the contrary, we showed it may be damaging for a reputable company to do so. A ported app of lower standards will cost less in the short term but the damaged reputation from disappointed users will cost a lot in the long term. As such it is better to not offer an app on every platform & device rather than offer a bad one. Apps that are tailored to the platforms and devices on which they are intended to be used will result in happier users. Having happy users is translated into good ratings, thus better reputation. Good reputation attracts more users and the larger the user-base the bigger the profit. To conclude, design native apps → profit.

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

Steve Jobs Never Listened to His Customers

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” — Steve Jobs

Apple doesn’t do market research; Steve Jobs never listened to his customers. [1] Customers use products, while producers develop products. It is hard for customers to imagine an ideal product without seeing it, and tell the producer what they want. Innovation is of great importance for the survival of a company. If a company can always put innovation in the first place, it will has a great many opportunities to give customers surprises, offering real attractive products to the world.

We are not Steve Jobs

Exactly, we are not Steve Jobs. Besides Apple, there are certainly other companies did graceful innovative works, and managed running successful business. However, lacking of requirement analysis in software developing can cause huge risks. What if a company has spent a lot of time developing software that customers do not really need?

For example, customers want a kind of software that can help children to be interested in reading. To achieve this goal, an attractive GUI is required, as well as a nice sound effect. Nonetheless, the company comes up with software with huge font size, saying that this is to help children to remember words better. In the end, it is probably that the software will be a disappointing product. You may think: how can a company be such an idiot? Well, it is just a simple example, what I really want to say is, understanding the requirement of a software is undoubtedly necessary.

Software Requirement Analysis is Like a Translator

The purpose of software requirement analysis is to understand the exact requirement of a product, and build a basic standard for the product. To be noticed, the requirement of software is probably changing all the time; as a result, requirement analysis is necessary to be done throughout the whole development process. Requirement analysis is like a translator, to help both the customer and producer to understand each other’s “languages”, so that they can have the same understanding for the product. [2]

Understanding the Background of the Software is Necessary

However, as a developer, does it mean it is enough if we just understand what customers tell us to do? Absolutely not!

One of the basic principle of software requirement analysis is to understand how the requirement comes, i.e., why does it needed. Why it is necessary to understand “why”? The answer is, we can know more about the background of the needed software. So, why it is necessary to understand the background?

A developer basically has a good skill of producing software of good quality; however, when the product is used in different situations, does it really of good use? The answer would be not sure. This is the reason why developers also need to understand background of the software. Besides the needs mentioned explicitly by customers, there are also some implied needs. A “good” requirement analysis can describe the required functions well, and help developers to come up with satisfactory functions for the product; a “better” one can go further based on the background. [3s]

For instance, if a chain company requires a system for handling their products sales status, so that the branch offices can collect and pass the data to their head office. This is quite a simple requirement for the product. However, after the analysis of the background of this company, it has been found that the company has tens of chains. As a result, the producer suggests a distributed and parallel system for the company, so that information can be managed without complicated manual sending and receiving processes. What’s more, data consistency can be easily achieved.

Understanding the Change of Requirement is Necessary

Understanding the change of requirement, or communication, is necessary. Communication always lies in the center of many processes of software development, in requirement analysis, it also does.

The key to the success of analysis is a perfect understanding of every requirement, while the requirement keeps changing. Today, your customer tells you he needs a kind of software to record how much money he spends each month; tomorrow, he may ask for another function for suggesting how to save money. When it comes across a large-scale software development project, the requirements change more rapidly, making the whole process more complicated. Thus, a good communication is of great value to help developers to know exactly what the customers want and catch whatever changes in time. Guessing the requirements of customers may bring a software product into a disaster.

So, a Good Software Requirement Analysis is Necessary (A Summary)

Of course Jobs is right, innovation can give quite a lot opportunities for a company. Infinite market researches or requirement analysis may stop his company from making progress. But as far as I can see, a large amount of software products need to be developed based on software requirement analysis.

Software requirement analysis is like a translator, which can help companies to understand what the customers really want (to obtain comprehensive and detailed requirements of customer), and keep pace with the latest requirement without omitting any small changes (to prevent the misunderstandings of the requirements). A good requirement analysis can help a company to provide splendid products for customers, avoiding wasting time and energies on useless works.

References

[1] Why Steve Jobs Never Listened to His Customers https://www.helpscout.net/blog/why-steve-jobs-never-listened-to-his-customers/

[2] http://blog.jobbole.com/49332/

[3] Davis, Alan M. Software requirements: analysis and specification. Prentice Hall Press, 1990.