Reflection for Bosch Project

15-Jan-2013Suleyman YILDIRIM

The structure of the reflection report is as follows. First, I reflect onthe moments of surprises, which I wrote down during the project, by considering both the technical and organizational point of views. Second, I come up with the rules of thumbs derived from the moments of surprises. Third, I reflect on the feedbackfromtheteammates and draw conclusions based on the feedback.

Moments of Surprises (MoS)

There are many moments of surprises that yield to rules of thumbs. I address them chronologically.

Date: November 7, 2012||Type: Technical Domain

I realized that I had an ability to think out of the box. To give an example, at the first week of the project, I made a lot of research about “interactive maps with HTML5”. After then, I found out that KineticJSjavascript librarywas a promising technology for user friendly maps. After I found a sample and adapted to our implementation, the team leader presented my work to the client at the first weekly meeting.The client appreciated the concept we offered in that the draggable floor maps was innovative solution. Based on the feedbackwe received, I continued to work on KineticJS which was the most attractive part of the implementation. Indeed, our project was selected as the best project by the product managers of the Bosch.

If I have enough knowledge on a specific topic, I can solve a technical problem in a short time. For example, my friends encountered a problem while they were testing my application on a tablet. The application was not working properly as it worked in the desktop. While I was trying to figure out the problem, I suddenly want to search the class definition of user events.Then, I found out that there were user events such as click, touchstart, touchend etc. After a while, I realized that the problem was not taking into account the attributes related to touch events. Therefore, I quickly wrote functions that enable the touch events and solved the problem just before the meeting.

Date: November 8, 2012|| Type: Organizational Domain (Cooperation)

The team came together to examine the web server code that had been written by Bosch engineers before. The main functionalities of the system depended onthe web server which should have been used for the next phase of our application.We discussed and examined the code each other for almost 3 hours. After the meeting, I realized that team work is more efficient than individual work.[C1] If I tried to understand it on my own, it would take much more time. I tried to keep that in my mind during the whole project and did not hesitate for asking help from my teammates.

Date: November 22, 2012|| Type: Organizational Domain (Cooperation)

Team work and planning: that is the key of success! Today, all of teams had the 3rd meeting with the client. Last week, one of the PD coaches made recommendations about the presentation techniques for customers. I proposed the team leader to apply these techniquesby finishing the planned tasks the day before the meeting and rehearsing it among each other on the meeting day. After he accepted my proposal, each team member followed that plan and finished their duties on time during the week. We rehearsed the presentation just before the meeting. It was the most productive meeting than the previous ones in terms of time management and conveying information to the customer efficiently. I would like to use the sameapproach for the followingin-house projects.

Date: December 13, 2012 || Type: Organizational Domain (Project Organization)

As we dealt with the 3D research which was a specific requirement of the client for only our team, we were behind our schedule. In addition, I was one of the main programmers of my team and also a test manager. Therefore, I had to write the code, realize the test cases and then warn the team members about the bugs in the application during the last 2 weeks.Doing both of the tasks at the same time was very challenging and an unexpected situation for me. Besides, it was even so bad that I was still checking the test cases oneday before the final presentation. Moreover, the team members choose me as one of the presentersonly the day before the final presentation at 09:00PM!This experience reminded me of “prison of the style”, [C2]as I always preferred to follow a fixedstructure. As a result,I realized that the software designer should have been flexible to the unexpected situations.

Rules of thumbs (RoT)

Rules of thumbs are derived from the moments of surprises are as follows:

MoS 2If I have enough knowledge on a specific topic, thenI can solve a technical problem in a short time.

MoS 3Ifthe team members cooperate and help each other efficiently[C3], thenthe amount of individual efforts decreases with the help of team members and the outcome of the team increases.

MoS 4Ifthe team follows a well-definedagenda for requirements engineering, thentheweekly meetingswith the customer will be more productive.

MoS 5IfI encounter an unexpected situation, thenI will not stick to my own style but employ a self-renewal for alternative solutions[C4].

P.S.: I could not derive a RoTfromMoS 1, as there was no condition for being creative. I just tried to my best and thenfollowed a different approach. However, there may be some conditions (i.e: anacceptable degree of autonomy inside the team, taking into accountthe team members’ proposals, an efficient communication among team members[C5]).

comments Peter d.d. 27-01-13:

your technical rules of thumb are valid, but not very spectacular. (Probably your technical performance was!)
same counts for the organizational ones. Certainly valid, but you could have derived a few somewhat sharper insights, I guess!
I think that following your description of what you did, this what you did was quite impressive.
Sometimes you could carry your reflection a bit further, e.g. with respect to specification (what presentation techniques specifically were helpful?) or with respect to the meaning of your experiences to yourself as a designer.

Feedback from the teammates

Based on the feedback from the teammates, I have basically two strong and two weak design competences. The strong ones are number 7 and 9, while the weakones are 4 and 8. When I compared the teammates’ opinions with my own thoughts about the design competences, I found out that there wascoherence to the some extent.

Strong Design Competences

Being creative, i.e. being able to find innovative solutions, for instance by exploiting analogies with other domains

I believe that during the project, I was creative and found innovative solutions. MoS 1 and MoS 2 support the peers’ opinion. Indeed, it is encouraging to be the only one to come up with a different approach of implementing interactive mapsout of the 17 people. As I indicated in MoS 1, this leaded to our team to be the first among others. This design competency is very useful for my development. In the following project, I will try to improve my performance.

[C6]Being able to validate and verify a design qualitatively as well as quantitatively

As a test manager, I had a specific role for verifying and validating the design. For instance, before weekly meetings with client, I tested the user interfaceand gave feedback to the team members. Moreover, I wrote the test cases and verified that we covered all functional requirements of the customer in the last week of the project. In addition, I proposed to use a common coding style among team members which was another aspect of the quality of the design.

WeakDesign Competences

Being able to make a risk management plan and to act accordingly

I realized that I needed to improve risk management skills. I usually adhered to be organized and followed a fixed plan. Being ready for unexpected situations is a part of risk management plan. Therefore, MoS 5 proved that “prison of the style” may hinder my self-renewal in unexpected situations.[C7] I think this design competency is the most important one to be improved.

Being able to work at the proper levelof abstraction

I both agree and disagree with my teammates. While implementing the interactive maps, I put too much effort to the details and violate the rule of proper level of abstraction. To give an example, drawing polygons, which represent the zones on the floor map, took a lot of time as I wanted it to be very fancy. On the other hand, if you work at theproper level of abstraction, it is likely that you foresee the problems. For instance, based on my knowledge about Agile Methodology, I proposed to make the testing every iteration. Besides, I predicted that during the testing phase we would encounter bugs in the system and I was right! Therefore, I warned the team members many times to start testing earlier.

comments Peter d.d. 27-01-13:

Here you elaborated the received feedback by illuminating the validity of it: this is fine. However, you could have carried your reflection further here as well. E.g., you could have made interconnections and found contradictions between the different pieces of received feedback. (For instance, isn’t being creative not more or less in line with a lack of risk management?) You could find patterns in this feedback which tell something about yourself and your design style (e.g., that you are a creative designer, with a somewhat ‘unplanned’ way of working). Then, you could reflect on the advantages and drawbacks of this style (e.g., being creative can be very fruitful, but can irritate fellow team members because of unplanned or even chaotic acts that I carry out). On this, you could base resolutions for your further development that are personally meaningful to you!

grade 8/10

I as a Designer

Suleyman YILDIRIM

There are many similarities between the design attitude of Yamamato and software designers. First, software designers have also a passion for their jobs. According to me, the passion brings about a great concentration in design process. When I am writing a code or searching a solution for the problem, I forget everything and time passes quickly. Ido not consider my job as an obligation. It is the same feelingthat Yamamato felt about making men’s clothes. It is quite natural to me. Second, software designers are in pursuit of quality. They do it not only for meeting the expectations of the customers but also for themselves. For instance, you sometimes hear a software engineers’ comment about their design as “beautiful”. Third, as in fashion design, we are inspired from the previous designs. When we encounter a problem, we sometimes search for the similar designs related to the problem at hand. In addition, in the context of Object Oriented Design, reusing is essential. Therefore, there are a wide range of design patterns which an every software designer should know by heart. In other words, the patterns are a kind of knowing-in-action that is used automatically during the design process. Another similarity is that software is specific to the customer. A design made for a customer may not be used for another. Lastly, expertise brings about knowing-in-action. The more you are capable of designing software, the more you find accurate solutions to the problems without too much effort. You do it automatically. Moreover, I do not believe that any software designer will encounterwith a problem like “prison of the style”[C8]. Style means maturity, accuracy and expertise.

In spite of the similarities, there are also some differences between two disciplines. The first one is that fashion designers deal with directly physical entities such as jackets, shirts and fabrics. On the other hand, software is an abstract entity in that you cannot design by hand. Although we are also concerned with deployment view of the software product, we generally make an abstract modeling. Second, software design is based on the scientific facts rather than art. Although there are proponents who regard the software design as a king of art, it is a quantitative work. There are some aesthetic issues such as a code convention[C9] which makes a code “beautiful”. However, this doesn’t affect the main functionality of the design.

According to me, a good designerhas to have very well good knowledge and expertise in his/her area. He/she also has to solve the given problem efficiently, have good communication skills with the customer and his/her team. In addition, an ability to adapt changes of the customer’s requirements is crucial. Being a good team member is also very significant as most of the projects are done in a team.

As I do not have enough experience and expertise, I do not regard myself as a good designer. I need to acquire more technical skills such as Unified Modeling Language (UML) and design patterns as well as communication skills. I would like to be aware of new technologies and be a fast learner. In addition, I want to improve the time management skills as I work too much but not efficiently. Moreover, the most important skill that I want to improve is software modeling. I know that there are a few people who are capable of abstract modeling, even in big companies. Understanding the problem and transferring to it to the UMLwill be great skill for my career.

comments Peter d.d. 06-12-12:

you listed all relevant aspects of design: a complete account

your English is excellent: you are able to express your thoughts well

nice overview of your prospects of professional development: this makes your account personal

good report

grade 8,5/10

[C1]Wow. Often, it is opposite… (lengthy meetings etc.)

[C2]then what specifically IS your prison of the style?

[C3]I agree. But this is often hard to achieve… It would be nice if you developed a rule of thumb (or more of them) to describe what to do if you want to achieve this!

[C4]a good one. How difficult was this for you?

[C5]that’s nice, that you give credits for your personal success to your colleagues as well! And indeed, fruitful creativity is probably often conditional. A rule of thumb could then for instance be: ‘If you want creative ideas to be fruitful, make sure there is an acceptable degree of autonomy inside the team’ etc.

[C6]very good that you illustrate the received peer feedback with real experiences that you had during the project. It corroborates your finding!

Same counts for the next one (DC 9).

[C7]though this remains a bit vague. In what situations is this self-renewal so important? Is it not just human or even prudent to hesitate in the face of an unexpected situation? Why then be so brave? Wouldn’t every risk management plan warn against the need for unexpected defense against unexpected monsters? Isn’t the meaning of risk management a avoidance of unexpectedness by trying to predict as well as possible, long beforehand?

[C8]well, I guess I don’t agree with you on this…! Indeed, style means maturity, accuracy and expertise, but the automatism of it may also hinder your self-renewal which is needed in unexpected situations. Then, rigid adherence to your own style could imprison you.

[C9]a mathematical solution to a problem may be ‘elegant’/ ‘beautiful’ as well, while math is quantitative too!