Flop'n into the Internet

A blog about new and old technologies 

[flipflopimamop-blog]

Seth Besmertnik: Get to Know Your Colleagues

I found this interview with Seth Besmertnik especially interesting because of my experience working IT support helpdesk and being different from the typical antisocial IT guy. I found throughout my time fixing computer problems that holding a small side conversation goes a long way in brightening their day and getting to know them a little better. The interview with Besmertnik focuses on managers having conversations with their employees and providing them with valuable feedback in a productive manner. 

Besmertnik focuses on addressing personal feelings when providing constructive criticism because it keeps people from getting defensive. Approaching employees or coworkers with feedback in a timely manner is also important because it will also avoid long term problems. Besmertnik makes point that no feedback can cause employees to feel unappreciated and build up negative feelings to consider leaving the company. A positive alternative to this would be to provide feedback in short memos or emails to employees when they are successful to show your appreciation for their work. These short messages can go a long way with employees that are trying to improve their work ethic and understand where they stand in the company.

Corporate culture varies from company to company, and Besmertnik mentions that there probably will be differences, but similarities can be drawn between them. In his own experience, he brings up weekly Friday meetings where jokes were told and new hires were put on the spot to “break the ice” by asking them to put on a speech in front of the company. I have had a similar experience with my previous job where I was made fun of for wearing a tie on my first day. Feeling somewhat embarrassed would be normal in this case, and I never wore a tie to that job again, but it also taught me about the relaxed social culture that I would be immersed in for the next year.

Besmertnik’s interview mainly focuses on communicating with coworkers in the workplace. Feedback should be used frequently when employees finish projects and assignments to give them a benchmark for their quality of work. Corporate culture differs among companies which can make it imperative to communicate with new coworkers and figure out the expectations set for you. Communication is key for all of these aspects of professional development.

[flipflopimamop-blog]

Paul Maritz: One Leader to Four

Paul Maritz, president and C.E.O. of the software firm VMware, says leadership teams need a strategist, a classic manager, a customer champion and an enforcer. Credit Jim Wilson/The New York Times

Paul Maritz, the President and CEO of VMware, was interviewed back in late 2010 by Adam Bryant focusing on leadership and characteristics that make great leaders. Maritz explained about his personal experiences working for Microsoft in the mid-1980s and how he went from managing five to ten employees, to close to 10,000 people by the time he left. From his experience leading so many people, he learned about how successful people structure their lives to get feedback and be self-aware. In addition to these conclusions he derived from this experiences, he also found that there is no such thing as a perfect leader. 

Paul Maritz goes on to explain that there are four vital personalities for a great leadership team. These are the visionary, the classic manager, the customer champion, and the enforcer. The visionary is someone who works to plan for the future and devise a strategy to meet end goals. The classic manager takes a traditional role in dividing work and takes care of the organization. The customer champion focuses on making sure the product appeals to customers and voices concerns and issues that would come from the target demographic. Finally, there is the enforcer who pushes the group forward and knows when to move on from an idea or problem. 

This part of the interview really resonated with me, since it breaks down what type of leaders a group needs to be successful when developing a consumer product. I’ve worked on small committees of eight or less people and I have seen conversations go no where even after hours of talking points. Breaking leadership down from one position into four major roles based on teammates’ personalities can balance out the leadership and form a more well balanced team. In my future careers, I will be looking to form teams balanced as Paul Maritz explained because I feel that it creates an interesting dynamic to accomplish goals and complete projects as efficiently as possible.

[flipflopimamop-blog]

VuFind & Mifos X FOSS Projects

VuFind Overview

Developed at Villanova University, VuFind is a portal designed to allow users to search and browse through a library’s resources. A quick scan through  VuFind’s website reveals plenty of information and features about the project, documentation about how to install and configure their software, and even upcoming events held in Germany. It appears that the project is still active; the last release was 2.4.1 back in late May 2015, but it looks like the project has a major update at least once a year. After a bit more searching, there doesn’t seem to be a clear starting point for someone looking to get involved without following a link to GitHub. For a project that is holding international meetings with German Universities, I’m surprised to see that VuFind does not host their own code. Overall, this seems like a very credible project that is far along in its development process, but it still has some growing to do before it becomes a standalone open source project.

Mifos X Overview

Mifos provides an open source platform which allows service providers to deliver financial services to impoverished third-world nations. The Mifos community has a presence on many popular social media sites such as Twitter, Google+, Facebook, and LinkedIn. They encourage followers to share their stories and encourage others to support Mifos mission statement, a powerful tool to advertise their cause without spending vast amounts of money. For the developers and testers that would like to get involved, the Volunteer tab provides all of the information necessary to write code, test feature specifications, become an adviser, and even write documentation for other users. The Mifos website contains plenty of information about their mission and includes links for road maps, current documentation, and donations to keep the project alive and moving forward. Overall, the project appears very credible and established with its funding and partners. I would expect development to go far with the help of volunteers and financial backers.

[flipflopimamop-blog]

Requirements Gathering

Jim Heumann vs. Karl E. Wiegers vs. Thomas Hathaway

Jim Heumann wrote an paper called Writing good requirements is a lot like writhing good code which argues that developers can effectively serve as requirement engineers with the proper training. Heumann divides requirements into four categories: business needs, features, functional software requirements, and non-functional software requirements, which make the suggested types in the IBM Rational Unified Process. He goes on to explain that requirements should be written in a declarative format with a subject and verb in each sentence to make them easier to test and read. Since this is a paper for developers, he also goes into detail about coding guidelines and knowing your operating system environment which are both fundamentally important for developing the system once the information gathering stage is finished.

Karl E. Wiegers wrote an article titled Writing Quality Requirements which focuses on software requirements specifications (SRS) and the characteristics that come with writing quality requirement statements. Wiegers recommends the following six characteristics for a good SRS document:

Correct

Feasible

Necessary

Prioritized

Unambiguous

Verifiable

He goes on to explain that a high quality SRS document will also be:

Complete

Consistent

Modifiable

Traceable

The characteristics hat he lists are not expected to be part of every written requirement, but he recommends keeping them in mind to help produce better SRS documents.

The final article written by Thomas Hathaway called Business Requirements - What Is The Difference Between Good And Bad explains that good requirements come from three major stages, ‘Capturing’,’Clarifying’, and ‘Confirming’. Hathaway explains Capturing as gathering information through interviewing, observation, analysis, etc. Clarifying requirements is to make sure that more than the author fully understands what the requirement means. This is important to make sure the end system fulfills the actual needs of the requester. The final stage of confirming is very similar to clarifying, since it confirms that the business side of the project and technical community interpret the requirements the same way.

Although each author takes different approaches to requirements gathering, they are all fundamentally the same when it comes to their characteristics. All three writers mention that requirements must be clear and concise when being recorded so that readers will interpret them in the same way. Differences between the authors come when they break down the details of their requirements gathering process. Heumann breaks requirements down to four categories based on IBM’s model and focuses on how they should be written. Wiegers breaks down requirements into six characteristics with an additional four to strive for. This is a much more detailed approach when it comes to analyzing requirement statements. Finally, Hathaway takes a much simpler approach by breaking down the requirements gathering process into three major stages which encompasses the ideas of the other two authors in a more general sense. 

[flipflopimamop-blog]

#irc

Internet Relay Chat. 

Something that I thought died a long time before my generation seems to be still alive and chatting away within online communities.

So why have I decided to investigate this strange medium of communication? I may have partially been forced to by an assignment in one of my college courses, but there have been other times where IRC has peaked my interest and I explored what I could.

My first opinions of IRC come from the Windows application “Mirc” which is one of the most downloaded IRC clients to this day. As you can see below, the interface is very similar to instant messenger and its first few prompts help setup nicknames and servers.

I joined #ubuntu to start with an active channel since it was one of the first places I remember going a few years ago when I first explored IRC. I found it strangely quiet when I got there, only the occasional system output of a user entering or leaving. After a few minutes of silence I asked where I could find information about active channels and to my surprise, the channel came to life with many helpful answers. Users actually linked bots that were designed to find active channels and that could be passed parameters for specific search criteria. All useful information for a new IRC user like myself.

It turns out that the #ubuntu channel is dedicated to helping people with their Linux questions (mostly pertaining to Ubuntu) and I was directed to another channel called #ubuntu-offtopic for more of a traditional chat room setting. Opening another window to this channel revealed many IT related professionals talking about their jobs and what they have to put up with on their day to day. Funny stories about coworker mishaps and snide remarks of other departments provided an entertaining read for the time I was there.

For computing professionals, I can see finding specific answers to difficult IT problems here because of the level of expertise by the IRC users. I would find it hard to believe than an average computer user will just happen to stumble upon and IRC client, pick and register a nickname, and connect to a channel. The people using IRC must have a decent IT background to figure out the tech jargon and have some direction to get to these online communities.

My initial thoughts about IRC led me to believe that it would be chaos. Everyone coming and going in channels, saying whatever they want without filters, I expected text to be scrolling on my screen faster than I could read. But to my surprise, both of the channel’s I visited were civil and quite friendly to visitors. Now I’m not naive to the fact that some channels are chaotic and poisonous, but I was happy to see that it was not the first thing I discovered and I will definitely have to visit again when I have some spare time.