Second client meeting reactions

Our second client meeting took place last Wednesday with Nikan. In the first part of meeting, we had to report what we had been doing since the first meeting. Each member of the team told Nikan the tasks we accomplished last days. In my case, I spent most of the time learning how to use Ruby on Rails by reading and watching some helpful tutorials. Additionally, I added some possible challenges to our "brainstorm" list, as well as prepare part of the user story second version (required by our client due to this meeting).

Next part of the meeting was to review the new version of our user story. Nikan asked several questions, especially focused on details about functionality, usability, as well as design, buttons, information displayed, screens, distribution, etc. She also asked about a global timeline for all the team members, but we only had a tentative timeline, and probably not as detailed as she wanted. For this reason, Nikan suggested to bring a new version for the next meeting.
Finally, we review the team member's tasks for the next week. I was assigned to develop the user's profile screen, and the challenge selection page, which also includes a module with the current challenge. As Natalie and I are novice in Ruby on Rails, the team decided that we work together in order to help each other, which will be definitely very helpful for both of us. Therefore, we started working on Wednesday afternoon...

Personal remarks:

- Despite our client did not ask about a story board, I think we did a great job by building one using a whiteboard. But we made a mistake because we only brought to the client meeting a picture of the story board that we displayed on a smartphone (it seemed not as serious as our client would expect) . We should have copied it, using any software, and turning in a hard copy to Nikan.

- Regarding the user story, I noticed Nikan wanted to be sure that what we were talking about would be exactly what she will have at the end of the project. The user story we turned in was quite detailed and completed, but in my opinion, we probably should have added parts of the story board to give a "graphical approach" to all the process we commented on the user story.

- We need to build a full time line for the whole project, describing the weekly tasks for each team member. I believe that the quickest way to create such a complete timeline should be to use a free software, ProjectLibre for instance. I used it on my Carpooling 505 project proposal, and it is very easy. Anyway, the idea in terms of the timeline is to focus on the application's functionality and then, once all works fine, move to the design and testing tasks.

First team meeting: Database model & story board

Last Sunday, we had our first team meeting. Two of the action items for the day were the design of the database model, and the creation of a story board for the application. The database model should include all the models, entities, relationships, as well as the fields associated to each entity. On the other hand, the story board  for the application is a detailed sequence of each screen which users are going to see when they are working with our application. Therefore, thanks to the story board, we could easily understand what we were putting, and where.

OK, that was the idea. At the beginning, we scheduled to do first the database model, and we actually started working on it using a big whiteboard provided by Matthew. When it seemed we had an acceptable model and moved to the story board, we quickly noticed that we forgot to add several entities, relations and fields on our tentative database model.

For this reason, I realized the importance of such a simple thing like a story board. To build it, it is very important that ALL the members of the team take part, because some characteristics or functionalities of each window could be overlooked. We finally got a well-detailed story board, which was also very helpful to complete the database model at the same time we added new stuff, as well as fix any previous database decisions. Apart from all I wrote so far, and based on the first team meeting experience, I would like to say two additional comments about the use of a story board when we face a new project:

1. Once the team gets an "officially" complete story board (this includes an accurate review by the team members), it may be interesting and especially useful, to share it with an outsider (several persons outside the project, if it is possible), because he/she could find mistakes or overlooked parts, even new features that nobody in the team thought before.

2. A good and accurate story board ensures an easier user story design. Our client claims for a "great user story, that absolutely will work by project completion", so if you have a great story board, you will have most of the work done to create an user story that satisfies your client expectations.

I always believe we can take advantage of our mistakes, and I will put more attention to the story board design in future software projects.

Ruby on Rails first steps

As I told in my last post, I am a rookie in Ruby on Rails. Following my teammates recommendations, I started the Rails for Zombies tutorial. After few seconds watching the first video, it suggest to do the Try Ruby tutorial before continuing if you do not have enough skills on Ruby programming language. This was my case (in fact, I had never used it before), so I actually began doing that tutorial.

Once finished the Rails for Zombies tutorial, I obviously have a more clear idea about how this framework works. The First levels are easy in general, however, last levels are quite messy because of many new concepts arise, and it is difficult to memorize all this new stuff. In any case, the tutorial itself is really helpful in order to take your first steps in Ruby on Rails.

I found the RoR (common abbreviation for Ruby on Rails) directory system particularly difficult to catch up. Despite the tutorial emphasizes several times on the folders and files structure, it is really hard to remember all the locations. Additionally, this structure is fairly different from other languages, but it seems like all this mess will make sense when you improve your RoR skills.

In the meantime, I discovered a website with the RoR directory structure, as well as a brief description of each directory. It has been very helpful for me. On the other hand, I found the following animated graphic that shows one of the main features of RoR: the Model-View-Controller (MVC).

Model-View-Controller Architecture (9lessons.info)

Honestly, I do not expect to become a RoR expert by doing this project, mainly because there are only eleven weeks left to turn in Demigod to our client. Anyway, I hope to gain enough skills in this new (for me) programming language, at least to be able to implement simple developments from scratch and have a wider vision of what kind of things I could do by using RoR.

First client meeting reactions

Our team had the first client meeting last Wednesday with professor Ackley and Nikan, who act as our customer. We were slightly confused about what our client expected. We  need to turn in a user story which will work at the end of the project, and we tried to do it before the meeting, but it seems like we were not accurate enough...

Professor Ackley asked us about specific features, screens, buttons, as well as examples of concrete challenges which Demigod should have when it is launched. However, we probably did not prepare the user stories as detailed as our customer demanded, causing sometimes a lack of understanding between the members of the team. I noticed how professor Ackley, as a customer, he tried to be as much precise and clear as possible, and he took notes about all the features we described (lesson learned for the next project). This part of the meeting took not more than 15 minutes, but from my point of view it was more important than we may think, because our customer, base on the user stories, could require certain functionality at the end of the project, and our team must take into account all we say in this meeting. Otherwise, the customer may not be satisfied with the product, and what is much more important, he will be absolutely right.

On the other hand, the last part of the meeting was basically to assign tasks to each member of the team. One of my tasks for this week is to get to know Ruby on Rails, which is the framework we are going to use and I have never in my life worked with. I am facing its installation and setting up on an virtualized Ubuntu 12.04 LTS x86 (for this purpose, I usually work with Virtual Box, that gives a really good performance, and is free). Additionally, we have to think about the possible challenges included on Demigod. I believe the best way to deal with this kind of things is to discuss between all the team members, but in the meantime, we are using a Google doc as a "brainstorm sheet" where anyone can add ideas and suggestions.

Keep going working until the next client meeting.

Just joined Demigod project

Congratulations to the CS 460 winning projects, from my point of view, they all deserve to be implemented. I was lucky  in the team members assignation, because the project Demigod created by Matthew Smith was my second choice (just after my own proposal). Finally, Demigod achieved was the most voted proposal among all the projects, so I am completely sure about I am going to take part into a really ambitious project.

I felt particularly attracted by Demigod, because of its innovation. The idea of merging different kinds of "challenge" applications (in this case physical, nutritional, and intellectual) in the same project is something that I had never thought about, but it seems really useful for the final user.

Despite not having skills in the programming languages and tools which our team are going to use (Ruby on Rails framework and Twitter Bootstrap), I am looking forward to start working with this project. I can contribute with my knowledge and experience in other projects as well as designing websites.

We have our first client meeting in a few hours, and we have to turn in a user story that can convince our client. In other words, something that will work properly at the end of the project. I believe that this is our first challenge, if the first meeting success, our client will have much more confidence in us along the rest of the project.

Anyway, I hope it will be okay. We form a great team, with multidisciplinary members, which is always an interesting point when you face a project.

My top 5 project proposals

It was not easy. In fact, it has been very hard to select just five among the twenty five project proposals in the CS 460 class. I would like to congratulate all my classmates for their projects, because from my point of view, we did a great effort trying to boost up and promote our proposals following a common approach that has come up several times during the last weeks: believability.

I think there were awesome ideas that will not finally be implemented, but I tried to focus my votes on the originality and usability, always keeping in mind in which project I would like to participate taken into account my skills and preferences. Therefore, this is my top 5:

1. Carpooling 505 - Fernando Serrano: It may seems "over self-confident", but sincerely, I would like to see my idea working in the real world, even though I do not take part into the project. Besides, despite not being an idea that "will change the world", I am completely sure that it could be very useful for the Albuquerque inhabitants.

2. Demigod - Matt Smith: Nice pitch! I felt particularly attracted by this novel idea, as well as the way Matt introduced the project to the rest of the class. I definitely would like to join this project!

3. Powderade - Kishore Jogia: Honestly, I am keen on snow sports, and this project sounds really good for me. In addition, I think it is an interesting way to compete with your friends while you enjoy getting to know ski resorts.

4. Carbon Counter 5000 - Ben Mixon-Baca: I would never in my life had thought in a carbon gamification. Apart from being an very original idea, it could contribute to reduce pollution while people enjoy playing a game.

5. Mechanapp - James Vickers: This could be a really helpful application for mechanics. Putting together all the experience and knowledge of them, it would be easier to figure out how to fix a car problem. Great idea!

Good luck to all the participants!

Reactions about software design patterns

In software development, there are a lot of common issues that usually arise in different parts of the process, not only in development, but also when we are working with interfaces design, for instance. Software design patterns form the basis to look for specific solutions to common problems.

Thus, a design pattern should be seen as a workaround for a design issue. These solutions must fulfill some characteristics such as a tested effectiveness, as well as be reusable in order to apply them to multiple applications and environments, under different circumstances.

These are some of the goals of software design patterns:

• Provide reusable components to software systems design.
• Avoid unnecessary searches about known problems which have been already solved and tested before. 
• Establish a common way to solve problems among software developers.
• Set an standard design model.
• Make learning easier for rookie designers by taking in advantage the existing knowledge.

There are three main shorts of software design patterns:

- Creational patterns: focused on facing object creation in different situations.This pattern avoids possible design issues or an unnecessary complexity increasing.

- Structural patterns: Wikipedia defines structural patters as design patters that "ease the design by identifying a simple way to realize relationships between entities".

- Behavioral patterns: This kind of patters are related to the interactions between the objects in order to avoid dependencies and hard-coding. In contrast, we can get a more flexible communication between objects.

I am particularly interested in lazy evaluation, that is not recognized as an "official" design pattern. In fact, the design pattern is the lazy initialization, and according to Wikipedia, lazy evaluation is a "general treatment" of the lazy initialization.
Lazy evaluation is especially used in functional programming languages. It basically provide a mechanism that delays the evaluation of an expression until its value is needed, avoiding repeated evaluations. Thanks to lazy evaluation, the execution time of certain functions can be strongly reduced, as well as memory usage in some cases.

Eager evaluation (also called strict evaluation) is the opposite of lazy evaluation. This is the common evaluation way in most programming languages (operators such as +, -, *, /). However, there are expressions in eager languages that are evaluated in a lazy way; a simple if clause for instance (if X then Y, else Z).

For example, to implement lazy evaluation on Boolean expressions (also called "short-circuit evaluation") using Java, we can use these syntax: &&, ||, instead of the eager operators (&,|):

public boolean isTrue() {
    return exprA() || exprB();
}

The second expression (exprB()) will not be called if the first is true. The OR operation has the same behavior as the AND:

public boolean isTrue() {
    return exprA() && exprB();
}

The second expression (exprB()) will not be called if the first is false. So, it is clear that we can reduce the execution time by applying lazy evaluation whenever it is possible. But, there are also some disadvantages, because lazy evaluation can make a code difficult to understand when we have troubles or exceptions. It also makes debugging tasks more difficult to deal.

Project final proposal: Carpooling 505

The final proposal for the Carpooling 505 project is ready. I made same changes and additions based on the Professor Ackley's reactions, as well as the reviews from both David Strawn and Kishore Jogia (thanks!).

Download the final proposal (V.1) for Carpooling 505.

Reactions about the Goldilocks Method

Honestly, I did not know almost nothing about the Goldilocks Method until we speak about it in class. Wikipedia has the following definition: "The Goldilocks process is a process of initiating and sustaining systemic change."

A systemic change implies a kind of change that embraces all parts of a system and their possible interrelations. So, the Goldilocks Method may be used to start up a systemic change, such as a project or a design. From my point of view, this is a really interesting method to success a presentation, because most of costumers tend to fit into the Goldilocks Method approach. In other words, they often look for a well-balanced solution, and take the minimum risks for their business.

Following this way of show a design, we can ensure that our customer knows both the upper and lower bound. The boundaries are usually associated to take risks and "extreme situations" in same way (and customers tend to avoid them), therefore, they are not the best solutions. For this reason, using the Goldilocks Method, the boundaries are actually the key part of the presentation. We talk about the "bad story" (lower bound), and then, the "good story" (upper bound). Once the boundaries are set, it is time to sell our idea as the best one. At his point, if we did a great job, we will have a "clear path" to success.

In terms of a design, the Goldilocks Method could be proposed as "X is too ugly", "Z is too hard", "Y is the best". We can think about broad features or "facts" of our design, creating questions based on those features. Finally, it should be easy to classify the questions and their affirmative answers into the previous categories ("X is too ugly", "Z is too hard", "Y is the best"). This is the process to get a bunch of facts of each category, which can be used in the presentation to convince our customer. The goal is: "Our design is exactly what you need".

This is a good example of Goldilocks Method application to choose a book. It is very useful to check how it works.

Software craftsmanship

The term of software craftsmanship is quite new among the software development language. First references abut this concept arose more than 20 years ago (1992), when Jack W. Reeves suggested in one of his essays that software development "is more a craft than an engineering discipline". However, the first serious steps of this movement began in the late 90's.

Nowadays, the definition of software craftsmanship is not clear yet, mainly because it is an abstract term, and each person who tries to give the definition, does it using different approaches. In my opinion, that is the main reason why today we do not have a widely recognized definition.

I will not try to set a definition, I will just talk briefly about this term. In my opinion, software craftsmanship is a trend, a movement that considers the work made by developers an art. It claims the need to be proud about the developer's skills to write code from scratch, creating something that may change the world in some way. It also leads to consider all the features of the software development itself, such as professionalism, responsibility, constant improvement, precision, capacity of learn new things every day, the quality of the developed software, etc.

Software craftsmanship is, in my opinion, a crucial part to understand what software development really means. We should take into account that not all the things related to the word 'craftsmanship' must be tangibles. The more developers follow this movement, the better software will be developed in the future. And what is more important, they will be proud of the product that they create, boosting towards more motivated developers.

Three words to define an ideal project team

It is not easy to describe what an ideal project team is in just three words. In fact, a good team must meet a broad number of characteristics, but if had to select exactly three words, I would choose the following ones:

- Adaptability: We live in a world where changes in many ways are part of daily. Unfortunately for project managers, developers and any other members of a team, what was accepted and approved yesterday, today could be slightly different for our customer, and what is worse, completely different for us. For this reason, an ideal project team should be composed for people who are able to adapt to any kind of change, such as the schedule, requirements, resources, as well as know how to work with different methodologies.

- Commitment: From my point of view, this is the most important feature in an ideal project team (if I had to choose just one). A project team must be exactly this, a TEAM. All the members of the team must show a commitment to the team itself and to the team’s goals. If we have a team with this property, the chances of success are really high. Commitment is a characteristic especially important in agile methodologies, because there exists a higher frequency of feedback between the members of the team and also with the customer.

- Responsibility: A project team should also has the capacity of being responsibly of its duties and tasks, as well as over its achievements. In this sense, the responsibility must be assumed by each member of the team, with no exception, because they should feel responsible for their own work, and also for the work of the rest of  the members of the team. Thus, lack of responsibility in only one component of the team may lead a project failure.

I discarded the following three words from the final selection. However, they are actually a very important bunch of features for a project team:

- Motivation: this characteristic is crucial not only in project teams, but also in many other things of daily life. Sometimes, lack of motivation implies employees who are not happy with their work, and this could be a huge problem. The project manager must try to maintain worker's motivation, which often guaranties great results.

- Communication: Among the discarded options, this is my favorite one. Communication is a key feature because every team is composed for PEOPLE, therefore the members of a team NEED to communicate each other to report information, feedback, instructions, opinions, etc. In my opinion, the worst thing that could happen in a project team is lack of communication.

- Leadership: All the boats have a captain, all the soccer teams also have a captain, and project teams are not an exception. The figure of the project manager is essential to lead the team and choose the most appropriate option in any occasion. Teams with non-defined leader may easily fall into internal troubles and disputes between their members (a kind of 'civil work').

Proposal Review: Kishore Jogia

I reviewed the proposal created by Kishore Jogia. He wants to develop a mobile application for skiers and snowboarders which is able to set your (and your friend's) real-time position on the trail map of the ski resorts.

Download the proposal review for Kishore Jogia's project.

Proposal Review: Sonny Trujillo Jr.

I reviewed the proposal made by Sonny Trujillo Jr. about creating an opinion analyzer using a web crawler that will read information on the Internet.

Download the proposal review for Sonny Trujillo's project.

Agile software development: When & Why

The use of agile software development methodologies has been increasing in the last years, this is a fact. We can easily check it by taking a look to some projects carried on by software development companies.

Recently, I took part into a software project in Spain which was made following a Scrum methodology. It seemed that the features of this project did not fit properly with an "ideal" Scrum scenario, however, I was not the project manager, so I could not decide what was the most appropriate model.

I have had the opportunity to speak with several project managers, and I noticed that some of them talked about they "prefer" agile methodologies rather than the classical iterative models. In my opinion, it is not correct to speak about what methodology we prefer. Each project has its own characteristics, a specific scope, different kinds of final  users, etc. For this reason, we need to find out what is the most appropriate model, and try to avoid getting carried away by our fashion trends. I believe that talk about which methodology is in general "better or worse than other" is something that does not make sense.

Taking advantage of this topic, I am going to enumerate the features for scenarios that, from my point of view, could fit with a Scrum approach, which is actually one of the most popular agile methodologies:

When to use Scrum?

• When we are going to face complex projects developed in dynamic or continuously changing environments.
• When the customer needs quick outcomes.
• When flexibility becomes a requirement.
• When product requirements change frequently.
• When we have to identify and fix deficiencies systematically.
• When the success or failure of the project is defined essentially by the responsiveness to customer requests.
• When the customer is involved in the project.
• When the project team is self-sufficient.

Project draft proposal: Carpooling 505

Find below the link to download my final proposal (draft) for the Carpooling 505 project (PDF format). The original version of the timeline has been modified because I noticed that the project may not success by using a Waterfall model as development methodology. Thus, I finally chose a more agile approach (iterative model).

Download the final proposal (V.0) for Carpooling 505