The Team

The team is not an amorphous mass. It is made up of people, each of them unique in his own way with his own values, beliefs and experiences. It is made up of Serban, Mihai, Dragos, Marius, Cristi and so on. A team leader should preserve and cherish individuality. He should not think of his team to as a pool of resources that is there to complete given tasks but rather how to help each member express his ideas and allow each and everyone to participate in the project creatively. He should find ways to involve people and and let them do their jobs as they see fit. Rather than imposing his point of view, he should strive to generate consistency from all points of view and maintain the project heading forward. This is especially true for game development, an industry that focuses on fun and, since fun is a subjective matter in most cases, more opinions are always welcome. Treating each person as an individuality has, potentially, the following benefits:

• People are more motivated if they feel its their project they build and not a series of unrelated taks
• The outcome is better since it is the mediated value of many opinions
• People work better if they feel that they mean something in the team and see the importance of their job
• People understand better what is required because they are directly involved
• A sense of friendship occurs from many people working together towards a common goal
• Knowledge is spread within the team
• Know-how is put to better use since everyone finds his place within the team and the project
• People end up liking what they do and develop a sense of confidence, leadership and attachment to the project
• Generates better visibility of the team members outside the team, to upper management
  

A common pitfall is getting lost in details and endless meetings but this can be properly managed and its the duty of the team leader to make sure the project is not stalling. A lead or manager should never forget that is the team who builds the project and not himself.

Ubisoft @ BEST Festival in Iasi

Last week BEST (Boart Of European Students Of Technology) had a festival in Iasi. Ubisoft was invited to present itself and to sustain a contest of game development. Both the contest and the presentation were a success. To my surprise though, many students were not aware before the presentation that those cool games outhere are, in part, developed in Romania. Yes, they are and the Bucharest Studio has a strong position within the Ubisoft group. Brands fully developed in Bucharest:

• Silent Hunter (3, 4, AddOn)
• HAWX
• Blazing Angels (1, 2)
• Chessmaster and many more.

Also the Bucharest studio took part in developing other well known games, in collaboration with studios from abroad. Yes, a career in game development is possible in Romania and yes, you get to work at the highest level.

The picture represents me, sustaining the presentation.

Notes On Software Engineering And Software Architecture

Before diving into any argumentation I'd like to point out that I strongly believe that software development should be scientifically managed and developed, that patterns are good and that at no time one should start coding before thinking first about the implications of what he is doing, about where that code should be merged, about what his task is all about and how. Yes, think before you do! The main concerns a software engineer should have are:

• Do I perfectly understand what is the scope of my taks?
• Do I perfectly understand what is the scope of the program and where my task fits in it?
• Do I perfectly understand previously written code - or at least its main concepts and structure?
• Am I making sure I am not duplicating functionality?
• Can I fit my task onto existing patterns and structure, what are the existing pieces of code that I can reuse (not copy-paste)

If you are not sure about any of the questions above, it is imperative to ask!

In the lines above I've tried to avoid using the terms "software engineering" or "software architecture". They are good terms, they summarize perfectly the concepts of solid development but I feel that, by being overused, their meaning is somehow lost.

What is engineering and what is software engineering? Well, since the beginning of the century students were told that engineering is the act of using theoretical principles and forces of nature to build something useful. The focus is not on the process of "engineering" but rather on the work product - yes, engineering is not a process and it's not even a fixed guideline. I'm making this point very clear because many developers gather under the term of software engineering a whole personal philosophy of how software should be done, what rules should be applied, how code should be written and they think it's the fault of the management that these are not followed - however, each developer has his own philosophy. This creates around the term a mystical aura and a sense of guilt that pushes the notion far away from its original meaning = use your knowledge to build something useful.

Something similar is with software architecture and many think of software architecture as a predefined set of mandatory classes, a lot of links between objects and, generally, a huge amount of code, formatted according to his own style. However this defeats its main purpose: to help us do more with less. According to my view, software architecture is that basic set of principles the code is build upon that minimizes the size of the program, that facilitates code reuse and discourages hacks. Its purpose is to limit the quantity of non-feature-related code and therefore to limit the amount of bugs. Ideally, it should allow the developer to think only of his task or feature and should make very clear for him what is there to reuse and how things are organized. This definition fits very well under the KISS principle, however most of us have the tendency to forget it and get caught in the thrill of building systems - our OWN systems.

Yes, every time you feel the need to build a system stop and ask yourself: why? - and try to be honest about it - are you developing it because it is cool and you want to show off a little or because it is really needed? If it is really needed, you may want to think again.

Systems are not bad by themselves and many times they are useful. What makes them bad is that, sometimes, their scope is not perfectly defined, that the developer tends add code that "might be useful in the future" and most of the time it is not; they increase the amount of minimal knowledge about the program one should have (there is this system, that system and the other one - which one should I use?), usually they don't fit on existing architecture and, in the end, they only add extra complexity if not properly managed.

Many times "architecture" is done on an egocentric basis rather than feature-centric and that is not pragmatism. Most of the times, the best code is the minimal code required to perform a certain task. If it's proven insufficient, one should have enough energy to refactor it. Failing to do so leads to cowboy coding and hacks in no time especially if changes are not properly managed. A large program is, by itself, a complex system and his structure should be revised constantly and, if it's not fit, modified. Such a task is usually huge and of vital importance and should only be undertaken by the most experienced developers in the team.

Working With Junior Engineers

During the last four months I had the pleasure of having some new, junior programmers in my team. Working with them, I realized the enormous benefit of inner motivation. While well trained, they also posses a proactive state of mind that pushes them forward at an incredible pace. I hope that, next time I feel close to loosing my motivation I will remember the following lessons:

• Competency is not necessary related to experience (especially in IT) - there are a lot of highly trained junior engineers outhere!
  
• Constant learning and willingness to self improve is the only way to keep pace with the freshmen.
• Inner motivation is extremely important. Young people have it and its helping them achieve things that some may think only a senior can do.
• It is easier to work with junior engineers because they want to learn and to demonstrate what they are capable of (again inner motivation)
• In a team it is good to have the right balance between seniority and juniority. Senior and junior people tend to complement each other - while the first have the skills the others have the motivation. Junior engineers will inject energy and will increase the motivation of seniors. On the other hand, juniors will have some to learn from to achieve a higher skill level faster.
• Proactiveness is pushing things forward and its one of those key ingredients that we don't ever want to loose.
• Since it is not (most of the time) possible to have a team made up of only senior engineers, juniors can prove a valuable choice especially if the company is also interested in investing in people and future projects
  
• A project can fail if not enough senior resources are assigned to it - due to lack of expertise
  

Karim Rashid - Design Your Self

Ever since "Publica" print house published Karim Rashid's "Design Yourself", everyone seems caught up with it. Skeptical at first, saying to myself "yet another book to teach you how to live your life" I took it and started to read. At first, I was impressed by its looks. Glossy pages, colorful, different. Inside? Short and to the point. Urban. Solid and simple ideas about how life is and should be lived, packed in a trendy design, written especially for us, people in the whirlpool of city life. The basic idea the book is constructed upon is that less sometimes means more - how to organize your house, your desk, your shopping list. It also emphases that you should take your life in your hands, not be afraid of challenges and changes, develop yourself and express your personality as you see fit. It may sound like a cliche but the book is well written, short, colorful, full of examples, some of them being quite funny. I had a good time reading it and it also made me think about things that I should change in my life. Good one :)

Note:


Another post on books: Books That Shaped My Last Year (2010-2011)