On Teamwork

Group projects are inherently difficult. Many different people working on the same thing, with different skill levels, backgrounds, schedules, etc. It is hard. Often there is this idea that everyone must do an equal share of the load. I think that idea is silly and completely non-realistic. I have been on many group projects, in academia and otherwise, and I have never experienced people equally sharing the load. However, this does not upset me, rather I think it is the only group projects can in reality function.

When you start a group project, some people are going to have a higher skill level in the various areas of interest. This is natural, and even good. The best thing to do is then to divide those people up, based on their skills, and have each person work where he can do the most effective job. However, you will inevitably end up with multiple people working on the same task, with different skill levels. Expecting the less skilled person to do more or equal to than the more skilled person is insanity. Why would anyone expect that outcome? But if one is to take issue with this, then you will find yourself always dissatisfied with group performance. Rather, the metric by which you should be evaluating your compatriots should be their ability to perform the tasks they say they can, in the time frame they give. Perhaps you could have done it twice as fast, but that is not an issue as long as you are still working on other tasks than more work is still being done. The less skilled person, by performing the task becomes more skilled in the process, which helps the group as a whole.

To be more concrete, our project revolves heavily around web application architecture. This is an area that I am very familiar with, so I have more skill and understanding in the are than some of my teammates. As such, I have performed more work than some of my teammates. But I in no way feel that this means that they did not carry their share of the load. They did want they could, when they said they would, and I have been very satisfied. If our project had been focused on a different technology, say robotics, I would likely have been doing the least quantities of work rather than possibly the most, just because others would have had a better background in that area.

Libraries

Modern applications are so complex and do so many things, that all but the largest of development efforts rely heavily on open source libraries to bootstrap themselves into a real working application. We are doing this in many different ways in our application. This includes grand large open source libraries, such as our framework, to smaller and perhaps more scary libraries like a google+ auth plugin (Not written by Google).

As the recent Heartbleed bug has show us, there are dangers to using such tools, but what else can a developer do? It would be some form of madness to constantly reinvent the wheel. Further code you write yourself is no less likely to not have bugs just as damning (often more likely).

How does one vet these libraries before including them in your application?

On "Real" World Features

Introduction

Our application is nearing it's final completion stages for the semester. Throughout the course of the semester there has been pressure for us to add "real" world features. By "real" world features, I specifically mean, domain name, web accessible (rather than running on localhost), google+ and facebook integrated login, etc. While I understand the importance of these features in a real world application, which this may become, I feel that having them be part of this iteration of the application is a very bad idea.
These features are all associated with a few common issues, cost, personal identification, security (which in some ways are all sides to the same coin, a three faced coin...). Because of this I don't they should have been requirements or requested for this application. We included them largely without objection for fear of being evaluated more negatively (from an academic perspective) if we did not have them. The mechanisms that drove the evaluation process are so opaque to us, that we felt it better to just fall in line.
However, I do think that it is appropriate to address the issues with this features.

Domain Name

Problem

Registering for a domain name on the internet requires that one disclose a substantial amount of personal information to a third party. This is often not a big deal for a company, which already has all of its information listed publicly, but is not something that a student desires to do. Further it costs money.

Alternative that works just as well

At the end of the semester we will be doing our final pitches for our applications. At this point in a real world development cycle, many applications would still not be on the web but rather running locally. This would be intentional in order to keep the not yet launched application underwraps. After a backer was found you may put it online. Certainly this is a debatable point, perhaps some applications would have the site up in development and even before it was backed by a venture capitalist, that's true. But we are students, and it is perfectly reasonable to have our application not sit on the real world wide web, or at least, it doesn't need a domain name until a real launch.

WWW Accessible

Problem

Making the application accessible on the world wide web, with real hosting, costs money, opens up the system we use to the very real perils of being a server on the world wide web, and if we use a hosting service again requires us to divulge personal information.

Alternative that works just as well

Run it locally. Just like for a domain name. Maybe an argument could be made for having it on the world wide web for the final pitch, maybe, but definitely not during development.

Google+ and Facebook Login

Problem

In our modern world, your social media/email accounts are very important, and a very high target for hackers. If we implement the login improperly (which happens all the time on the biggest of web applications) then we expose real people to the real problems of getting their accounts hacked.

Alternative that works just as well

If our application must be web facing, then there is not alternative. Implementing our own login features is more likely to have security issues. But, as previously mentioned, the application does not need to be internet facing.

Summary

So this is my little rant on the features that I do not think are necessary or even good for our application. I am not too upset about them, but thought it might be something to consider for the future. I understand why they are desired, they bring a sense of reality to the projects. At the same time, while we pretend to be in the real world this semester, we should not forget that we are actually still students.

How to manage then unmanagable

So this past week has been one of the busiest of my life. I have slept 15 hours in the past 4 days. I am not writing about this to garner a pity party, but rather to ask a question. What do you (whoever you are) do to stay productive when it seems like there is not enough time?

From the studies I have read, sleeping is always better than not sleeping, even when you are busy. But I don't know if the people who wrote these studies were computer scientist students also working 20+ hour a week jobs.

So when the rubber meets the road, I don't sleep and eat like crap. And I usually get everything done. What do you do when there isn't enough time?

The Increasing Cost of New Features

As our project has become larger and larger I have noticed a much greater cost for adding new features into the codebase. This is almost always the case for any non-trivial project, however this cost seems particularly painful right now, perhaps due to the busyness of my life in other areas as well.

The latest feature that I have been working on adding to our application has taken much more time than I had thought to implement.

This is also one of my largest flaws, estimating how long it will take me to complete a task.

New Features

In the past few weeks, I have had a much greater desire to add new features to our application. Now that things are mostly together and I can see the product for what it is, it seems like it is hard not to see it for what else it could be. This is not to say that I am unhappy with our project I think we hit our goal and things came together better than I had expected.

At the same time, there are several things that I really want to add to our application. The rest of my team does thinks they would be great, but doesn't feel that they have time to add them. I have to say I rather agree, but it still irks me nonetheless. How does one "finish" a project?

Tedious

As we get closer to the end of the project, more and more of the features that we wish to implement require less and less interesting work and more tedious work. This is not to say that the features themselves are boring, they are certainly not, they are quite cool to have in the application. However web applications involve so many moving parts, that in order to do them securely and correctly, you have to do a lot of boiler plate.

I find myself getting excited to work on a new feature, only to quickly lose interest as I realize all of the small indirectly related sub tasks that are much less interesting.

I wonder how one learns to make these small tasks more enjoyable, or if that is even possible?

Presentation Thoughts

This week my group had to do a mock presentation of our application to the rest of the class. It was a rather strange experience, in that there was not really enough time for the four of us to each speak in a fluid manner, leaving a single speaker and three generally silent members.

It felt strange to me, to be a silent figure at the front of the class. The role seems to imply some form of direct interaction upon my part with the presentation, although really there wasn't any. There was plenty of indirect interaction, through showing the body language of approval and interest in what my team member was talking about, but that was about it.

I was not dissatisfied with my team members presentation, on the contrary, I thought that it was very well done. It only felt as though there should have been more time, or I should have not been standing there. This isn't really a critique against the professor, because I am well aware that this situation occurs all the time. I just wish there was a more organic way to deal with this type of presentation.

Small Changes

Currently I am working on adding some new features to Mechanapp to allow for user login and persistent user session. Both of these items are in and of themselves not very complex or difficult to implement. However, implementing them in a good, safe, reusable manner is another story entirely.

User login, demands that we are sending user credentials back and forth on the network. This means that we must now start encrypting the traffic with TLS, as well as purchase a valid TLS cert (if we want anyone to actually use this application). Further both login and persistent user session (by which I mean tying state to a user id rather than a cookie), require that we introduce a second database that will be much more mutable than our previous one. Until now our architecture had remained pretty simple, but at this point it is getting more complex.

It is strange how such small features can have such a large ripple effect in the application.

Formal Attire

Tomorrow we have our first demo presentation of our software. There has always been an age old question about these types of events, what should one wear? I know this sounds silly, but hear me out. Often at the large CS conferences, the main speakers will wear t-shirts and jeans, the formal attire of the programmer. Is this the way to go? Or are these people just being lazy? I often think that people who wore a suite to such events would either have to be James Bond cool or they would not be taken seriously. In our final meeting we will be presenting to business people, which lends itself to a more classically formal attire, but what do you wear for other CS people in a formal engagement?

Meetings

Over this semester I have had a very interesting experience with meetings in my group. Generally our group has met at least once a week often more than that, and observing these meetings has been strange. Often it seems that we are get very little done during the course of the meeting. We discuss some high level topics and that is about it. It seems that most of the real discussion actually takes place in email chains and the like. This is not to say that the meetings are bad, on the contrary they are perhaps the some of the most enjoyable times during my week. It seems that our group has the fortunate (or unfortunate) issue of getting along too well. We get along so well during our meetings that is is hard to keep them from becoming just hang out sessions.

Reflecting upon this, I am not actually sure it is a bad thing. Certainly we have somewhat of a hard time accomplishing the tasks we wish to accomplish during the meeting, but they do get done shortly thereafter in emails and other forms of communications. Also I feel like the group bonding time is really good for our cohesiveness as a team.

Running out of Time

So at this point we are pretty late in the game. There are only about 6 weeks left in this semester, and that is really not a lot of time. This puts us in a awkward position with our project, and by us, I mean me. There are several large new features that I would like to implement before the semester is done, but I don't know if we will have time to get them in place. I really feel that they are killer features, but with so little time, I feel that I don't want to lobby for help from other team members until I am at least sure I can get them off the ground.

This puts me in a very sticky situation. Work on new features that may never see the light of day, or focus on polish of the existing codebase?