Author: s1006617

What open source is

Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone. [1]

Generally open source software is maintained by inidividuals that work on the particular project for free. However, various companies allow and even encourage their engineers to contribute to open source for various reasons. In my experience the hardest part of contributing to open source is getting started so I will give some advice and pointers to some resources to anyone wanting to contribute to open source.

Why you should collaborate

Working on an open source project gives software engineers the opportunity to work on a set of skills they wish to enhance while benefiting of the support they get from other contributors.

Secondly, experience gained from open source sontribution is a great topic to talk about in an interview in industry. It shows that you got to practice a set of skills that are important for the job you are applying for.

Last but not least, it is a great way to give back to the community. Most of us use open source software (e.g. Android, Linux) so I consider only fair to give a hand in fixing bugs, or writing test or documentation, or in any other way that will make the porject better.

On  a side note, during lectures we’ve been told that companies choose to create an open source intiative that will go hand in hand with or support some other source of revenue (e.g. their servers or the ads they serve). It makes sense, and I don’t want to disagree but to add that, for example, I have seen interviews where Google engineers were saying that the reason why Chrome started is that they were Firefox, but Mozilla was being slow with improvements, so they decided to create their own browser to create competition for Mozilla. Another version I heard, is that they just thought why not have their own browser. I would have found the second version hard to believe, but then it’s very similar to how Gmail started so it is plausible. Unfortunately, I can’t provide references to these two stories, as I have seen them a while back and can’t really remember where.

How to start

The first time I contributed to open source was in  the second year of my degree when we were required to contribute to an open source project of our choice as part of a Software Engineering coursework. We did receive advice on how to pick a project: ensure there are multiple contributors to the project (minimum 2), ensure the project is not stale (i.e. there have been recent contributions made to the project), pick something that seems interesting to you. In my case, lack of experience did take its toll because while I did try to follow recommendations I still didn’t fully understand them.

Since then, I’ve become slightly wiser. My following advice is not a secret, they are the usual advice one finds in blog post of this type, but this is also what experience has taught me and I hope it will help anyone thinking of contributing to open source but doesn’t know where to start.

Don’t just look for a project with a couple of developers, look for a project that has whole community behind it. In most cases, these communities have a forum, a mailing list or irc channels which they use to communicate, which are a great media to get in touch with people already working on the project and ask for help. It is often the case that an active wi,ll be beginner-friendly and have good tutorials that will get your started. [2] and [3] are great examples of good communities where one can start contributing to open source. In my opinion it would have been a good idea for my course to allow students to contribute to such projects as long as each student brings different contributions (e.g. fix different bugs, add tests for different parts of the project or write documentation for different parts of the code).

When checking whether a project is stale, don’t only check when the last release was made (this should be in the last month) but also how often code submissions are made and how active the community is in terms of posts.

[4] is also great resource that helps people to start contributing to open source. They provide tutorials that teach people how to use tools such as version control and working with tar archives. They also have a database of tasks that need work which can be filtered by project, skills or difficulty. Moreover, most of the tasks have mentors, or people that are ready to help anyone willing to contribute to their project.

Finally, anyone can start their own open source project then get other people to contribute to the project. If you have an idea get some friends and start your own open source community.

References

1. Open Source Initiative [online]. (2014). Available from: <http://opensource.org/>. [Accessed 14/03/2014].
2. Ubuntu Wiki [online]. (2013). Available from: <https://wiki.ubuntu.com/ContributeToUbuntu>. [Accessed 14/03/2014].
3. Mozilla Developer Network [online]. (2014). Available from: <https://developer.mozilla.org/en/docs/Introduction>. [Accessed 14/03/2014].
4. OpenHatch Community [online]. (2013). Available from: <https://openhatch.org/>. [Accessed 14/03/2014].

This post is a response to “Duality of Project Management: objective vs subjective factors”: https://blog.inf.ed.ac.uk/sapm/2014/02/14/duality-of-project-management-objective-vs-subjective-factors/

The point I got from the original article is that management is more than telling people what to do; it is also nurturing the team one is in charge of. I completely agree with this idea.

In this post I will provide my own arguments as to why I believe a manager is more than someone that tells programmers what to do. Most of these opinions are based on my experience as an intern in a large software company and observing the interaction between managers and engineers.

In my opinion, managers are not dictators – they should not be telling people what to do; they should be both a leader for their team and a liaison between the team they are running other parties involved. I will clarify my understanding of what a leader is in a lower section.

Managers don’t dictate

Managers should not decide, programmers should. As much as I believe agile development is the best approach to developing a project, I understand that sketching out a plan in the beginning is very helpful for all the parties involved to have a broad idea of how implementation is going to be approached and how resources should be allocated. In some companies, the manager is responsible for planning the project and its implementation. What I suggest, is that managers involve the entire team in this process, since the team will be the one to write the code. I believe each programmer knows their limitations and are more qualified to give estimates on their own work. In  addition, the whole team (that including the manager) should brainstorm a solution; that way they don’t miss out on any good ideas. In [1], Susan Cain proposes that introverts make better managers because they better allow their teams to express themselves. What I want to extract from here is not that introverts are great managers, but that good managers listen to what team members have to say.

However, the manager does have the final word. Some discussions will go on forever if allowed, and this is not my intention when I suggest sharing decision making with the team. If team members cannot reach a consensus, the meeting should not be prolonged and the manager should make a decision based on the arguments he/she has heard until that point. It will be the programmer’s job to persuade his/her colleagues of the effectiveness of their solution.

In my previous team, all decisions were taken together with the team – when brainstorming new ideas everyone (including interns) would come with their own and then the team would vote on which would actually get implemented. Of course, it is not feasible to make every decision as a team so each engineer had the freedom of choosing how to implement the feature they were responsible for, but other team members had the opportunity to make their own suggestions during the daily update meetings. The manager never forced any decisions on the team.

Managers are leaders

Managers should be leaders for their teams. There are many definitions out there of what a leader is [2], but I don’t want to make this too confusing so I will give my definition: a leader is a person that inspires people around him/her, they lead by being a good role model and they nurture their team members. As the original article proposes, managers should ensure their team members are are happy with their work. They should remember each member is an individual with personal and professional development goals and they should try to ensure the work they do is in line the individual’s goals as much as possible. For example, if they know someone is trying to get better at writing tests or is trying to work on their presentation skills, the manager should try to give that person the opportunity to work on those skills – as much as possible.

Moreover, managers should ensure the team works well together, and  they help each other. The best suggestion I can make is to have occasional team outings – optionally these outing can involve some form of team building exercises. For example, these outings can be as simple as having dinner together or as crazy as a day at a trapeze school with the entire team. During my previous internship our team would always have lunch together, sometimes even having a picnic for lunch. When I left the company they were preparing a team offsite

Managers are liaisons

Finally, managers are a liaison between their team and other teams in the company as well as their team and company leaders or customers.

Managers are responsible with communication between stakeholders and the development team. To be more precise, they are the ones to pass on the stakeholders’ requirements to the team and to communicates the team requirements (necessary time and resources) to the stakeholders. One could see project planning as a negotiation between the two parties: stakeholders give time and money and in return the team may deliver a piece of software. The more time and money the team gets the better the software is. However, more money and more time don’t guarantee project success.

In some cases the team might depend on a product developed by another team within the same company and being in good relations with other teams means the other team might be more helpful and more willing to develop a new feature even if it is not on the critical path for other projects they are working on. To give an example, during my last internship my project depended on other products of the company but required some changes to be made on their side as well. For my final presentation I wanted to give a live demo of my work, but that required that the other  team releasing their new version a few days earlier than scheduled. To my surprise, they were very understanding and did push the release ahead of time.

Conclusion

To sum up, I have talked about how managers should make decisions together with their team, how they should be leaders and support their team members, and how they are a liaison between their team and stakeholders and other teams; thus showing that there’s more to management than planning and following the development of a project.

References

1. Susan Cain (2012). The Power of Introverts.03/2012. TED [online]. [Accessed 01 Mar 2014]. Available from: <http://www.ted.com/talks/susan_cain_the_power_of_introverts>.
2. Wikipedia (2014). Leadership [online]. Available from: <http://en.wikipedia.org/wiki/Leadership>. [Accessed 1 Mar 2014].

Introduction

Early in the SAPM course [1] we discussed estimating size and effort for software projects. We know this a nearly impossible task but a necessary one. Despite all the effort put into techniques and formulas that are supposed to help with this problem software keep being delivered late, incredibly late or never. Maybe what needs to be adjusted is not the process of estimating time and costs but the process of planning a project. We should instead expect to deliver a project with a few missing components that we can add later on. (This could explain the success of agile development: if a nonessential component is not ready, the project can still go on and be delivered)

Motivation

Why is estimating project cost and size important? Because companies need these estimates to plan cost and human resources to allocate to the given project. Good estimates allow companies to commit to delivery dates for its product and not have to deal with unhappy customers, while bad ones  lead to projects going over budget, over schedule or even end up as runaway projects.

 

How is the world coping?

In an endeavour to handle this problem various techniques and formulas have been developed to help with time – effort estimation. As previously mentioned none are a perfect solution and it seems that the industry has come to accept that estimates are likely to be wrong, but they need a starting point so the described techniques will continue to be used.

There are three major techniques used for effort estimation: three point estimates, Wideband-Delphi estimates and COCOMO.

Three point estimates

The three point estimate is a formula for computing an effort estimate as a weighted average of an optimistic, a most likely and a pessimistic estimate.

In my opinion this is a simple and fast technique to get a rough effort estimate. Since we already know that estimates given at the beginning of a project are likely to be wrong and therefore a waste of time, it is preferable to move on as soon as possible.

Wideband-Delphi estimates

Wideband-Delphi estimating is a techniques for computing time estimates that requests the presence of a group of experts. They repeatedly discuss the implications of the project and give they own blind and anonymous estimation of project duration until all estimates are roughly similar. Giving a blind, anonymous estimate ensures the result is not influenced by external factors such as peer pressure.

COCOMO

COCOMO  is a formula for establishing effort estimates based on previous experience. This requires that all previous projects are well documented. In my opinion, relying  on previous experience is the best approach; however, it is likely to fail if the team changes as it is quite often the case in software development teams. COCOMO will be delivering optimistic estimates if suddenly several team members are replaced by other less experienced members; moreover the a team’s dynamics generally impacts the teams performance.

A technique that would help with damage control early on in the development process would be periodic reviews of the effort estimates they have committed to. This especially important as there are several factors that unknown at the beginning of a project and helps adjusting the resources to help with delivering the product.

 

Maybe there is light at the end of the tunnel

During an internship, I got to participate in my team establishing new projects to work on, and the process worked along the lines of “What can we do in the next year?” and “What can we build the the next three months” rather than “How long will it take us to build this project?”. The  yearly plan was vague and most likely to change but the quarterly one what we were really trying to achieve. In addition, the company’s policy was: “if you finish everything on time, then you haven’t challenged yourself”, so teams were encouraged to plan for more than they could realistically achieve in the given time. This also means that it was expected that teams would not attain all their goals for that period. Moreover, we were working on a project with frequent releases, so this made the concept of deadline rather non-existent, as anything that was not ready for release could wait for the next release.

I am sure many of you are wondering what keeps people from slacking off? The answer is: company culture. But this is another story. The frequent review of goals as well as the lack pressure from the company were very helped the team stay on track while trying to quickly move forward with the development process. 

In my opinion, this model can work even for companies with less frequent releases. As long as they prioritize the features they are trying to build. They can start by building the most important features or components first, and put everything else in an “if we have time” category.

Conclusion

As we appreciate the importance of structuring a large project: planning and allocating resources to avoid waste, experience has shown it it almost impossible to control all the elements that influence the successful completion of a software project. Experience has shown that adding structure to the process of building software is impossible and we should learn to live with the unforeseeable.