When you think of IT oriented companies, Microsoft will come up often. The CEO of Microsoft, Satya Nadella, was interviewed in the New York Times. He discussed some leadership lessons he has learned. One which stood out to me is about what drives him crazy in a meeting. Nadella says if someone outside the company says the way they are doing something is how we use to do it or someone in the company says this is how we do it drives him crazy. Then I continued reading where he describes taking all the experience to find the best for the current situation. Something I have noticed through my experience is how staying the same is not the best route and neither is adopting every new process. Every organization is different and not every process will work for every organization. This is something I am going to remember for the future. As someone who like to be using the latest technology, the latest technology or process improvement is not always the best. What I would do is look at the situation to determine the best way to move forward using ideas from current best practice and current ways of working.
I read an interview in the New York Times of Paul Maritz. Maritz discusses a leadership lesson he has learned. He said, “there is no such thing as a perfect leader.” Instead you can find around four different personalities on a leadership team. The four personalities are a strategist, a classic manager, a champion for the customer, and an enforcer. I found this very interesting because looking at my own experiences these are personalities I see at various levels of a company. Each person brings a different perspective to the table. I believe this reinforces my idea that a group of people leading something is always better than a single person. Everyone has their strength and can be very helpful if they are in the right role. When putting a team together, I am going to make sure to have people with some of these different personalities. This will help to make sure the team works great for everyone.
Students or people interested in coding usually work on small personal projects. If one wants to expand their skill and assist a community, one can work on a Free and Open Source Software project. I look at two FOSS projects to see if they would be a good place for a new contributor to start. The two projects were VUFind and Mifos. VUFind is a software for libraries to search through library resources. The software is developed by libraries and is modular so libraries can implement some or all parts of the system. Mifos is a platform designed to help bring financial services to areas of the world which do not have the services now.
As I was looking at each of these projects, I was looking at who was behind the project. VUFind is backed by Villanova University’s Flavey library. I guess that is where it gets the VU part of the project name. While a University is backing it, there are only 43 active contributors. This seems to be a small number but I guess it makes sense for a software aimed specifically for libraries. Mifos on the other hand is backed by an organization called Community for Open Source Microfinance. This is a non-profit organization which is designed to serve as the project sponsor. Based on data from Github, in 2014 there was about 40 contributors but recently it has drop to less than ten contributors. If you go to their Jira community where tasks and a wiki live there are over 500 people listed.
The community behind the project is only the start to looking if someone should join. Another area is how one can assist the project. Both projects have a Jira project to track bugs and features to be worked on. They also both have use Github to store their code repository. Mifos has a nice entry way for new contributors. On their website under the Volunteer page there is a link for introductory volunteer tasks. I could not find a similar page for VUFind.
One thing I noticed on both projects is at times it can be difficult to find how to get involved. It is nice though both have multiple communication tools used for users and developers to communicate. Both projects have an IRC chat room and email lists. This is helpful for new people to get information and ask question to get involved. The projects also have documentation for users and developers. The one thing I believe the projects can improve at are the websites. The website for VUFind needs more information on how people can get involved in the project. Mifos on the other hand has a lot of good content but it is not organized well. I think it would be helpful for Mifos to create a page for potential contributors to go to with links to other areas of the website. This brings key information to one areas and speeds up the time it takes to onboard a new contributor.
If I were looking to join one of these projects I would look more to Mifos. I personally find it easier to relate to a finance project then one for libraries. Mifos also seems to have a better entry point for new contributors and a larger number of people working on the project. Some might feel the more people the less I can contribute but as a new person on the project you are going to need help from people who understand the project better. The more people you have the more likely it is you will be able to get questions answered quicker.
Internet Chat Relay (IRC) is a group communications tool which is used by various groups including computing professionals. I joined a few channels on the Freenode IRC server including the Ubuntu channel. While on I was following a conversation around actions of running a shell script from a GUI. A group of users on the channel were helping this one person with their understanding of shell scripts. Then as the conversation ended you could see a person who was responding to the original user have an issue of their own. The purpose of a system for people to share their knowledge is great but IRC is the wrong platform.
I found it difficult to follow the conversation happening on the channel. First issue was I only was able to access the part of the conversation happening after I accessed the channel. This made it difficult at first to understand what a user meant in the first statement I saw of “right-click?”. The second issue was all of the system messages coming through every time a user joined or left the channel. At one point so many people were joining or leaving that my entire screen was just systems messages.
As someone who has used Slack, I find a few key features from Slack which would be helpful in this situation. One key feature is viewing previous messages which happen even when offline. This would help people joining in the middle of a conversation to jump in. Another major feature of Slack in threaded messages. Threaded messages would allow for users to reply directly to someone message in the channel. This would be helpful in everyone participating in a conversation to see all comments than scrolling through every message in the channel. The third feature from Slack which would be helpful is user status. Slack keeps a list of users joined to the channel and let you know if the user is online or offline in the list. This would cut down on all of the system messages within the discussion.
When starting a project, writing good requirements are important. The requirements are uses throughout the project and can set you up for success. After reading three different articles about good requirements, I found they match similar ideas I have based off my previous work experience. Two main ideas which I find similar are following a structure and confirmation.
Jim Heumann writes how developers can apply developer concepts to writing requirements. Developers need to structure their code to keep it readable and easy to maintain. The same can be used for requirements. As stated earlier requirements are used through the entire project. This means requirements need to be able to be edited multiple times in the beginning without repeating requirements. By organizing the requirements, you can ensure the requirements are consistent to meet the characteristics of good requirements from Karl Wiegers.
Confirmation is very important when moving requirements through a project. I have seen in my experience we read requirements from our own point of view. Sometimes we don’t stop to think how could others interpret these requirements. Thomas Hathaway discusses confirmation and prioritization. Part of confirming requirements must be assigning a priority to them. If a developer looks at a requirement, they might interpret a lower priority than the business usually because they don’t understanding the business. I have found the best way to accomplish this would be for the developers, requirement writers, and the business to discuss the requirements together. This allows for many of the different interpretations to be consolidated before working on designing the system. All of this work on the requirements early on prevents later rework because of misinterpretations of the requirements.
Writing good requirements is a lot like writing good code, Jim Heuman