Semester 1 SummaryTags: English, university
Created on Thu, 02 Jan 2014
Contribution and Achievements
This is not the first time that I worked in a team but it was the first time that the team wasn’t chosen by me but selected on random. So here is to what we’ve done during semester 1:
Create a team organization document. This was our first task as a team but we didn’t have much of an idea what organization should we describe - organization for the Team Project or the PSD assignments? I don’t think this was clearly understood. However we liked the agile methods so we tried to brainstorm about that.
Assign risks. Again, not clear in the beginning. We had no idea about the group assignments and what will this involve. And on the Team Project we were just getting started to understand the scope of the problem - too early to assign risks. So we tried to generalize them and later edit them and narrow them down as things became more clear (and after we got feedback) which was good.
Setup trac server and git repository. I think that was clearly described and we were able to set it up with no trouble.
Group work. We created the two prototypes of programs, trying to keep up with the principles of good software engineering (modularity, abstraction, incremental development) and of the Agile manifesto.
Team project. Our team won the award for the best team project progress. We worked hard, went through several design and architecture iterations, always working close to our manager, receiving constant feedback. Moreover, I believe that we truly want our project to succeed as we see it as something more than just a University task - we actually see the potential in the real world and I think that motivates us.
Despite the difference in experience of the team, we were able to balance the workload and give non-technical tasks to less technically experienced members of the team. I think my greatest personal achievement is patiently understanding the needs of the individuals and yet push them when the deadlines are soon and otherwise the tasks would be doomed. I believe this is a personal achievement since my character is usually much more temperament and I always try to take as many tasks as possible, hardly trusting other people. I think this semester taught me that given chance to people, they will do their best and providing constant feedback would stimulate them to work harder and thus gaining better results.
I wanted to give equal chance of tasting the leadership position to each of the individuals, however in the current form of the team there needs to be an experienced leader like myself in order for work to be done in time. I will try to take this lesson to the second semester.
In other words, the team experience outside of the classroom is various - some had summer internships, worked for companies part time, others didn’t have that option. In such a team if there is no hierarchy, as my experience during the first semester shows, work is done primarily by the more experienced members, widening the gap between the individuals and thus creating a typical Catch-22 scenario. What my plan for the second semester is that rather than concentrating on perfect tasks, we can concentrate on improving team stability and narrowing the gap between the knowledge and experience between the individuals. We can practice agile techniques like pair programming and code review. By producing slightly inferior code in the beginning and investing some time in initial bootup, I believe we can produce an overall better product at the end rather than huge deltas between the individuals of the team.
During the semester our regular PSD courses and homework assignments have thought me a great deal of how small and medium companies go through the process of defining the needs, capturing the requirements, making a plan and creating throw-away prototypes.
We learned about different design models, some historical like the waterfall, V and spiral and the more recent ones like agile development. I particularly like the agile techniques - they feel less “business and management” and more “computer science”. I have participated in three hackathons only this semester and created one myself to see that there is a specific culture among the IT guys. We like to do things quickly, play with it, throw it away and start from scratch if it doesn’t work. We are much more like children exploring the ways toys work than grownups who need exact plans and requirements. We can make things quickly and show it to our customer in a week rather than closing ourselves in months or years doing something and in the end failing to deliver whatever the initial requirements were. That is what agile is all about.
Of course, the rest of the world doesn’t always work like that. Therefore we find a balance between what we love and what our customers need. Hackathons and hackathon-like-coding is surely fun but rarely produces code ready for production, since there is no time to write comments, documentation and many times even the code itself is “hacky”. Relatively longer hakcathon-like coding in a week or two is a good compromise between fast coding and good coding. Thus comes the scrum method, identified by its daily standups and status reports and a fictitious leader who is also a developer like the rest of the team but just puts the hat of a leader in the meeting in order to facilitate the meeting.
Of course, we can’t start coding without knowing what we need to do. Here comes capturing of requirements. We had mock interviews with our professors in the University, a short, interview like tuning of the initial requirements. Additionally for our team project, we were having constant monitoring from PhD students and weekly meetings with our manager. The PhD students helped us define what is possible, viable and feasible to do given very high level specifications, iterating through different architectures while the manager started “lowering” the helicopter view he first gave us thus exposing us to more and more details. We are keeping documents in Google docs in order to always be up to date with the requirements as well as specific issues on github as to what precisely needs to be done.
Personally, I am satisfied with the course so far. We had a good amount of practical work, great 25/25/50 division between individual, group work and theoretical knowledge which I would love to see in other courses as well. Learning about theory and applying it in the same week is invaluable learning technique which lasts to years and not just for the exam. Looking forward to the second semester!
Week XTags: English, university
Created on Mon, 09 Dec 2013
Tomorrow is the team presentation. I feel we made very good progres in the last 5-6 days and now feel much more secure in what is going on with the architecture, final design and technologies that we will be using. Of course, we still haven't had any user evaluations but we are busy building the system which we will fine tune with A/B testing and direct user observation. We have tons of features waiting on the MoSCoW queue and also reflected in the github issue tracker. We have cleared some already but there are many more to come.
Week деветTags: English, university
Created on Sun, 01 Dec 2013
The second sprint didn't go so well as the first one. Maybe because of the many assigments that are due really soon and (naturally) everyone does everything in the last possible or beyond last possible moment. Another reason may be because we had to learn a framework for a week in between all of that. Spring is not hard, in fact, it looks extremely nice framework (maybe except the fact that it relies a lot on Java annotations which IMHO make the already hard to follow nature of the Java code even more unreadable). But otherwise the tutorials on the webpage are easy enough the follow and I also attempted doing one of the long tutorials - really nice, easy as a song (as we like to say in my home country).
Anyway, we were able to finish the prototype and we didn't spend too much time on goldplating the code and making it look pretty. It was mentioned in the specifications that this is not an HCI so we didn't want to wrap it in bootstrap or whatever css library we stumbled upon. I personally usually have the tendency to make the code look pretty on the back and in the front, most of the time in useless scale, but I think this semester taught me out of it, which was something that I wanted to change in me anyway. I think we were able to quickly skim through the specifications of the Spring framework, make our way around it, quicly distribute tasks among people which I wouldn't have been able to do in the beginning of the year now that I look back at it.
Week Math.pow((this.Week\ 10), $(this.Week\ floor(pi)))Tags: English, university
Created on Sat, 23 Nov 2013
Quality assurance. Good. Now that we’ve done implementing in our first sprint, it’s good for fresh eyes to have a look at the code. We were pleased to hear the other group liked the code and the design decisions we had while implementing. We also received a great feedback as to what can be improved. For example - we will shorten the commands so that the user doesn’t need to type the whole long string but just one letter. We got several ideas in places where we got stuck. We didn’t discover any bugs that we didn’t already know about but we did mark them clearly in our trac system so that we can squash the ones we know about.
As to the lecture - standardization is a great idea. So great that not one but many organizations exist that do standardizations in different areas in our life. Sometimes however I am afraid this thing happens as noted by Mr. Randal Munroe (xkcd 927 Standards):
Why does this happen? Why can’t we choose just a single way to do something? Actually, I notice lately that if there is even the possibility of doing something in more than one way, no matter how logical and ubiquitous the first one is - someone, somewhere will be the stubborn child of the world that will do the things differently. And will standardize it, and will preach it and teach it and will use it no matter what. Examples?
... Daylight Saving Time (look at 5:08) ...
... Driving on the left/right (2 possibilities, yet no agreement)...
... the Universal Serial Bus... UNIVERSAL!!!
Let me not even start on languages...
Week ^GTags: English, university
Created on Fri, 15 Nov 2013
The first sprint week looks really good now that it's its last day. We did manage to comunicate everyday with the team and hold standups - either through Google+ or live. We identified problems, assigned tasks to people and implemented our original idea with slight modifications which resolved issues found in the process. The course work seems good enough to be tested with the new (in our minds) agile scrum method of doing things. In theory agile sounds good, in practice it's even better. There is no more weeks of wondering if anyone did something and the frustration when someone didn't - everyday you have the chance to see what happened and help if there are any associated problems.
We decided to implement the course work in Python with data stored in a MySQL database so that we can brush up that good language that we learnt in first year and revise our database knowledge. We'll definitely need it in the second semester. In the first year we didn't do object orientation but now that I know the principles I saw its real power. I immediatly run to an object oriented approach to solve the problem and now I must say it looks really good - not just a bunch of lines, trying to do the prototype and get over with it. It's modular, extensible, with appropriate comments. We were also able to separate our tasks working on different files as to avoid merge conflicts. Using git as a version control system, we didn't run into any problems with it (which is always a big success, see Week floor(pi) post for example).
As of writing of this post we still haven't finished it completely as we need to populate our database and test it, but I feel positive about it. Back to work now!