Operations Research Honors

Dickinson College Senior

[orhonors-blog]

More Colored Hats

This week we discussed the success of the open source model, highlighting how different companies have benefited by promoting or building open source software, as well as the criticisms of the open source model, questioning the economic and ethical impact of open source software. I want to discuss remarks made by Matt Asay in his article, Red Hat’s open source success story build on killing complexity in IT.

In sum, we don't need just another Red Hat. We need many.

Asay begins by defending Red Hat’s formula, “making complex open-source software safe and secure for mainstream enterprise adoption”, as a critical requirement in a society flooded with open source projects that could benefit from a structured management and deployment. He states, “In sum, we don't need just another Red Hat. We need many.” This is where I start to see potential for businesses adapting an open source model. I mentioned last week that I could not fathom how a business could survive financially going open source. However, the Red Hat model that involves encapsulating an open source project’s complexity and delivering the product as a service, gives me a glimpse of the economic potential that can be drawn from open source software. So, I start to wonder, why are there no other Red Hat-like companies for other types of software that have been as successful. I could imagine a Blue Hat company for social messaging and a Yellow Hat company for databases. Strangely, this is not the case. Asay quotes Cloudera co-founder Mike Olson as stating, “If you’re operating a data center, you’re almost certainly using an open source operating system, database, middleware and other plumbing.” If that is the case, is every data center using software that they had to decide on, configure, and manage differently each time? This seems like a lot of wasted time that could be solved by an enterprise software management company that pre-configures and packages tools for customers to use without going through the hassle themselves. While there are a number of economic barriers in place that halt the success of open source software companies, I can almost guarantee that someone has tried to create another Red Hat-like company. So, I wonder what has limited or stopped their success.

[orhonors-blog]

Individual Involvement

This week’s topic was H/FOSS motivations: Who gets involved in Open Source projects and why do they? We looked at business as well as individual motivations for going open source.

Personally, I still struggle to see how businesses can survive on an open source platform. If it’s an already substantial company that forms an open source project, then they can most likely sustain that project. A smaller company or group may struggle to support themselves financially. However, that is the case for most start ups and some small companies that are not open source. So, maybe it’s my lack of fluency with business growth.

As for individual motivations, we found that individuals would join projects in which they had a connection or interest. We discussed the different roles that form in OSS as members transition from user, to bug finder, to bug fixer, to active developer, and so forth. I found it interesting that none of the class preparatory material discussed how the individual’s interest in a project’s community could motivate him or her to work. While my experience with joining communities is rather limited, I have found that I was motivated to stay and be involved because I knew that I could eventually become a core member of that community. I had an interest in the community and becoming a core member was something I looked forward to. By the time I became a core member, it was not as big of a deal as I had initially imagined, but I was still glad I put in the effort. So, perhaps individuals initially join open source projects due to some connection to the project. Their prolonged involvement in the project, however, may be due to the community and their interest in being involved in the community.

[orhonors-blog]

Get to work, Scrum!

I have always been interested in a project management position. Managing a project requires understanding both the big picture and inner workings of a project. However, project managers supervise the individuals in their team and need to motivate the team to succeed. This week we talked about some software processes, Agile, Scrum, Extreme Programming (XP), and Test Driven Development (TDD) to name a few. Many of the preparatory materials for this week emphasized that these processes are more philosophies than methodologies. The individual or team working on a project decides to follow a certain software process and designs their work environment around that philosophy. As a project manager, introducing a philosophy to a team can be difficult and sometimes end in failure. This is what I am most interested in: How does a manager introduce a new philosophy to a team and inspire that team to follow the philosophy?

Say I introduce scrum to a team on a new project. How much backlash am I going to get for “wasting the team’s time” at a daily stand-up meeting of which they do not see the benefit? The stand-up meeting is quick, holds individuals accountable, and gets ideas flowing for outside of the meeting. To those new to the philosophy, the stand-up meeting may feel invasive of their time and disrespectful of their ability to work. An article from Life Cycle Engineering argues that training people to use a process is often underdone by organizations implementing a new process. So, perhaps the solution to introducing a new process is to take a good amount of time to train the team on the new methodology before implementation. This could help the team understand the benefits of the new process and become more invested in following that process. While this is just one issue that a project manager might need to solve, I am sure it comes up often.

[orhonors-blog]

Polished Testing

Since I was unable to attend class this week, I missed out on the discussion of Software Testing with my peers. My post shall address some of my own testing concerns with a minor connection to the in-class discussion that I was briefed on afterwards.

Previous to this week, I had only considered Black and White box testing. This is when the tester knows nothing or everything about the code, respectively. However, I learned of Grey box testing where the tester knows the overall workings of a program but is not aware of the exact code implementation. I picture Grey box testing as the lead developer or project manager’s job. These positions need to know the scope of the project and, thus, can improve test design. In the reading, a testing myth mentioned was “Testers are responsible for the quality of the product”. Interestingly, if managers are considered Grey box testers, then the myth would be true, but I assume this is just a special case. In my opinion, Grey box testing is the most important box of testing since it requires the tester to step back from the code and examine the big picture of the software when designing tests. White box testing is useful to the developers and Black box testing works out all of the kinks in the end product. However, Grey box testing is a check, post-coders and pre-users, that can identify crucial errors in the software.

A small part of the in-class discussion involved estimating the number of bugs in code and determining the amount of resources to invest into testing. From what I’ve been told, the discussion reached the consensus that developers need to draw the line somewhere on testing due to either time or money constraints. While I agree this is probably a preferred tactic, in the gaming industry there have been numerous releases where a limit on testing hurt the software’s reviews.

Whether it be character rendering issues in Assassin’s Creed, launching errors in Dragon Age, or fps issues leading to the recall of Batman: Arkham Knight, the gaming industry is a prime example of where limited testing can be a negative influence on software. That being said, I encourage my peers to be cautious when testing software in the future. Testing is never complete, but it should be as polished as possible before release to users.

[orhonors-blog]

Applying Design Patterns

This week in senior seminar we discussed software design patterns. A majority of the students could recognize many of the design patterns as similar to work we had done in the past, just without the design pattern label. Design patterns were definitely a new topic for me, but I’m going to attempt to use them to analyze the current state of my honors project and devise some improvements.

For the general audience, I can give a very vague idea of my honors research that is enough to understand my analysis. I have a problem for which I’m looking to generate good, if not optimal, answers and I have multiple different algorithms for generating these answers.

In my implementation, I have a class that defines the problem definition. An object of this class is set as a static variable in many of the other classes that implement the various the solution algorithms. In my testing, it is highly unlikely that I will ever need more than one problem defined at a time, so it may be useful to apply the Singleton design pattern. The Singleton design pattern limits a class to instantiating only one object of that type. In Java, I found out that this can be implemented by making a static variable in the singleton class to store the object and making the class constructor private. This way, I could control when the constructor of the problem definition is called and only store a single object. This will reduce the possibility that I accidentally test the wrong problem and slightly clean up the code.

Also, for my solution algorithms, I currently have to instantiate each algorithm as its own class. When instantiated, the object will automatically run the algorithm on the problem definition that was passed in as a parameter. It may be beneficial to refactor the algorithms to follow a Strategy design pattern. The Strategy design pattern allows multiple classes to implement a collection, or family, of methods. That is, I could define an algorithm runner class that can setup, execute, and evaluate each solution algorithm. This algorithm runner would be able to take any of my algorithms, setup any parameters needed, execute the algorithm on the problem, and retrieve information about the best solution generated without knowing which algorithm it had executed. This could improve my testing process as the project continues to expand throughout the year.

I only touched on two of the design patterns we discussed this week, but I thought it important to note how I could specifically benefit from implementing design patterns on my research project.

[orhonors-blog]

Flaws of Development

This week’s topic of software flaws introduced us to warnings and ideas to keep in mind as we continue work on our respective projects. A few ideas that stood out to me were the importance of smart commenting, not coding for the future, and code review.  

In a previous software project, I implemented a grading plugin for an online grading system. In order to ensure the project’s longevity and ability to change, I added a lot of comments to explain the code process since even I found it to be a bit confusing once I stepped away from it. As pointed out by John Fuex in his 5 Best Practices for Commenting Your Code, “The need for excessive comments is a good indicator that your code needs refactoring.” After the grading plugin was complete, I took the time to compile a manual that detailed the workflow and important variable usage in an attempt to help another developer examine the project. Looking back, all of this should have screamed to me that the code could have been refactored, renaming variables and methods to improve understanding without the use of comments at all.  This refactoring, with a marginal amount of coding, may have vastly improved a future developers understanding of the project.

The last two ideas stood out to me as key features to never forget during software development. For starters, not coding for the future will save you a lot of initial time and effort. Factoring in the future should be easier once you know exactly what needs to be removed and separated. That is not to say that you should not plan at all, but do not accommodate for future requirements that are not immediately a concern. Secondly, code review is an important tool of software development. If a developer takes the time to get or make reviews of work, the developer can find sections to refactor and improve. Personally, I need to spend more time reviewing my own code. If I step back from my code earlier and attempt to find places of improvement, my overall development process will go a lot smoother.

[orhonors-blog]

Building to Change

In my senior seminar, we discussed the reasoning behind and types of software architecture. One quote that caught a lot of student attention was “building to change instead of building to last”.

When developing a project, one needs to think for the future. However, thinking to the future includes expecting the unexpected. By that I mean that developers should anticipate the changes that they can, but they should also anticipate changes for the entirety of a project. Features will be added in unexpected places and anticipating these changes can make their addition a lot easier and smoother to implement. This raises a question discussed in class: Is the end goal of software development, and by association software architecture, modularization?

Last semester, I worked on a web application project for the Spanish department here at the college. It’s a client-based application with a slight client/server, component-based architecture style. I say ‘slight’ since, as of now, there’s no clear distinction between the client and the server. One of my goals with the project was to eventually allow other departments usage of the project, so I modeled the database to easily accommodate new departments. However, I did not expect each of the small details that would be specific to each department; each department has their own data and constraints that the web application needs to accommodate. Some of the restructuring that’s required to meet these needs is the removal of some hard-coded elements that I believed would remain constant for all departments. Some questions for myself to consider: How could I have better prepared the application for these changes? Did I need to make more components that utilized higher levels of separation of concern? As I restructure the application, I want to define the separation between the client and server. Perhaps this separation will help reduce the amount of work needed to make a change in the future. I will need to look into what others have done for PHP projects and see if I can apply similar tactics for separation of client and server.

[orhonors-blog]

Communicating and Portfolios

This week’s senior seminar topic was H/FOSS roles, community, communication, and licensing. While that touches on quite a lot, I was intrigued by two things: the risks and rewards of commenting on others work and building a portfolio through open source contributions.

               Since freshman year, I have maintained an interest in software development--I enjoy creating tools to solve problems and improving those tools with user feedback. In most cases, building software is done on a team which ultimately results in commenting on others work. How do you comment on work, with appreciation or criticism, and keep the same level of respect and friendliness between individuals on a team? If the team is personable, this should not be too much of an issue. However, there is always the possibility of some group or person taking something too personally and creating a tension on relationships. In my past experiences, I have had to request comments on my work when looking for feedback. Before I asked, silence was how the team let me know that there were no problems and until I asked, I had no clue if they were satisfied with my work. Whatever the team, I hope I can find a decent balance between criticism and praise to keep each member of the team active, learning, and respected. Interestingly enough, one of this week’s readings mentioned that “when someone makes it clear from the start that he is going to be a fountain of bile, there is no point making him feel welcome". I guess that is a good judge of when changes need to occur and teams need to reevaluate themselves.

               Another reading mentioned that participation in H/FOSS projects gives the “opportunity [to] prove, to yourself and to others, that you can usefully contribute to real software projects”. I have spent much time working on software projects over the past few years, but none of them have been open source or hosted on any popular service (i.e. GitHub). I am now tempted to upload these project to GitHub as both a backup and a way of showing what I have done over the years. Being a senior, I am always trying to come up with a way to demonstrate to others, if not just to myself, the progress I have made over the past two years. It would be interesting to look into how non-open source developers generate a portfolio for themselves and how they distribute and represent that to employers.

[orhonors-blog]

Version Control Management

This week for senior seminar we prepared readings on different version control systems. Unfortunately, we were not able to discuss these readings in class, but I would like to share a few thoughts on version control management, focusing on authorization and locking of branches or files as well as briefly touching on one of the readings emphasis on a commit email system.

Many of the readings recommended that authorization in open source projects be kept to a minimum. That is, keep all branches open to commits and trust the developers to only edit what they need. While I do feel this is good for keeping developer self-esteem high and encouraging the developer to be aware of what they are editing, I will append to the recommendation that one should at least lock down the main master or development branch. For corporations this may not be the preferred method, but a locked down master and develop branch will guarantee that the project is advancing in a way that the moderators or managers want. An open master and develop branch may allow a project to progress more quickly, but could lead to more conflicts and errors if not checked. It could be argued either way although I’d prefer some sort of checking system.

In regards to an email commit system, one of the readings strongly encouraged, if not required, that a project have an automatic email anytime there is a commit made to the system. While this is a good way to keep an eye on the entire project, I would think the constant emails would get ignored by most. I imagine it similar to students at Dickinson College where a majority do not read or even open the daily newsletter email. So, my complaint is not with the email itself, but with the lack of attention it will be paid. An email commit log is a nice way of keeping tabs on a project, but the same kind of logging can be done by examining the project’s commit history. I would be interested to see how some companies display and track their development progress and how they have made it effective for their employees.

[orhonors-blog]

Expanding on Tickets

This week in senior seminar we discussed the management of an open source project; Management through organization, leadership, and some sort of ticketing system. I would like to talk about my experience with a ticketing system and how I have noticed tickets are managed.

In the system I use, tickets can be made and marked as features, tasks, issues, or bugs, with many more options available. Most of the tickets created have very detailed and specific descriptions, often with more details than necessary. However, these extra details usually make the assignee’s job easier since they do not have to figure out the minor details of the task. The details allow for a steady and constant workflow on the developer’s end that does not get halted by extra research or questions. I would say that tickets should always be as descriptive as possible, noting any instructions or resources that may be helpful to complete the task. By not doing so, the developer’s job has the potential to be increasingly more difficult due to a simple misdirection or error that could take hours or days to fix.

One semi-tedious part of the workflow, I have noticed, is finalizing tickets. When I finish work on a ticket, I mark it as ‘In Review’ and assign it to my boss. He then reviews my work, merges the code into the production branch of our software, and closes the ticket. This workflow puts my boss as one of the leaders of the project since he can decide when and what work gets added to the software. This puts a lot of extra work on project leaders since they have to track and manage their own updates as well as the work done by the other developers. While this is just one way in which the leadership of a project can be structured, it would be interesting to discuss how projects efficiently manage the work of multiple developers. Each developer has their own tickets and updates, but they all come together to form a solid piece of software.

[orhonors-blog]

A Bazaar-like Development

In my computer science senior seminar, we discussed the differences between open source software and private software owned by a company or other affiliation. I’m going to try and highlight a software development technique that lies between the two, balancing a private code base and a bazaar-like model for game development. In order to understand this comparison, I suggest noting the bold outline of the bazaar model found here. I have noticed many game developers employing this technique, but I will focus on Studio Wildcard, the developers behind the popular dinosaur, survival game ARK: Survival Evolved.

The game released as an Early Access which, by Steam’s definition, is “access to games that are being developed with the community's involvement“. So, right away a connection to the bazaar model through early release. User opinions are highly valued and their input is requested for future releases. ARK has constant updates and developer diaries where they frequently integrate user ideas and answer questions about the current game state. While this demonstrates Studio Wildcard’s dedication to building a community, their strongest user tool is the Ark Dev Kit that they released over a year ago.

The Ark Dev Kit is an application that allows users to create new content for the game that they feel improve or fix the gameplay and release it for use. Developer kits, or creation kits as they are sometimes called, are not new to the gaming community. What Studio Wildcard does differently is actively compile these user-made creations into the base (original) game. They can take these individual components created by users and add them into the game’s development. This lets the game be built and progressed by the community.

So, what has Studio Wildcard accomplished? I believe it to be a bridge point between the bazaar development model and private software. They have put user involvement high on their priority list, forming a strong community that can contribute new ideas through speech or direct development. They maintain a base, private code base while still inviting a community to form around the software’s development. Would other kinds of software be able to implement a similar development strategy or does this strategy only benefit games? A developer kit may be hard to create for most commercial software, but maybe there is another way to include user creations.

[orhonors-blog]

After-College

I’m currently a senior at Dickinson College. I’m undecided on whether I will immediately go onto graduate school. However, I am certain I will pursue a graduate program at some point after college. If I am able to find a job willing to pay for graduate school, I will definitely take that into consideration.

[orhonors-blog]

COMP 491

This blog will be used to post writings and discussion topics related to FOSS (Free and Open Source Software) projects and software engineering.