Project Constraints

Every manager knows that, given the quality-deadline-budget constraints, sooner or later he needs to "adjust" one in order to complete the project within the other two - especially if they are tight. Every project should find an acceptable balance between the three, a balance based on a trade-off limit established with the involved parties before the slippage occurs.

A question each PM should ask is: "In the most likely case that something goes wrong, what are my limits? What can I adjust?" The deadline and budget being rather fixed, given the market window opportunity and the sales forecast, is it quality then? It shouldn't be, as long as the quality target is within the application domain (e.g. no military constraints for a domestic use). Especially in our times of crisis and fluid markets - community sites, experts within reach, reviews, high competition-, lowering the standards of the product could mean a major drop in sales, or, even worse, brand compromise.

There is, however, an escape - the number of features. I can almost certainly say about every software project that is has at least one not-so-needed function that can be dropped off in case of emergency. What is there to do then? Well, I think the key word is prioritize: selecting that set of features that constitutes the core, that set that defines your project and makes it stand out of the crowd. These should be quite a few and be given the highest priority. Assigning a lower priority to the others, based upon business value and duration and making sure that you can complete the core and do as much of the rest as possible, without compromising integrity and quality should do.

As a rule of thumb: always try to make sure that a complete and coherent working product can be delivered at the highest acceptable standards, no matter what happens, and that all the stakeholders understand and agree with the compromises. And one important thing to remember: late cuts lead to inconsistencies, therefore cutting is something that must be prepared in advance. Ideally, all the times, the product should be coherent and marketable.

Flow

'Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.' - Wikipedia

Generating and maintaining his fellow coworkers in the flow should be the goal of every manager - a deep state of concentration and involvement that generates a rewarding feeling in those who attain it. The thoughts of a person in the flow are similar to a stream of ideas focused on a single subject. He or she disconnects from the outer world and becomes one with the activity thus resulting in a boost of productivity and enjoyment. That is why jobs like programming benefit enormously if the practitioner attains this special state.

Flow is not necessary related to work. Basically everything that is intellectually intensive can trigger such a mental state. One of the targets of every game designers is to create a smooth and immersive environment that, eventually, will capture players' attention and will trigger the flow. All successful games are able to generate such deep involvement that, in turn, creates addictiveness and satisfaction.

Prerequisites:

• A long period of silence and a surrounding atmosphere of involvement, lack of unnecessary distractions
  
• Intellectual challenge
• Streamlined tools or accessible interfaces (basically whole accessibility dogma is built upon the idea that a person shouldn't be distracted from his / her main activity and loose focus)
• Prior knowledge of the subject or some other mean by which the person feels comfortable with the activity he or she is involved in (like a smooth learning curve)
  
• A friendly but competitive environment

The main problem with the flow is that it installs quite hard and is lost quite easily. Repeated returns from the flow can be very unsatisfying and can cause frustration, boredom or a sense of general lack of enthusiasm. A programmer, for instance, needs about 20 minutes to attain flow and can loose it in roughly a minute or two of interruption. Therefore, it is imperative for a software company to maintain a low level of noise in the production department and for everybody to respect each others work and concentration. The simplest rules that can be followed that can have the effect of boosting productivity are:

• Maintain a low noise level (less talk in the production area)
• Don't interrupt your colleague for something that you can figure out yourself
• All discussions or meetings that need only a part of the team should be held in a separate conference room
• Maintain all activities not related to production to a minimum. When a colleague is doing something not part of his job, he may distract others
• Maintain short compilation and start-up times for the application to debug (in programming)
  
• Maintain the list of activities that one needs to perform frequently as short as possible; automate as much as possible. A single click or a shortcut should do most of the time
• Streamline all processes and reduce the overhead to the minimum
• Allow every employee to have enough personal space. Distribute desks such that everyone can have a feeling of intimacy and safety
  

Having said that, I wish you all to enter the flow as often as possible and to sustain it as long as possible. It's really fulfilling!

The Broken Window Effect

A broken window - not a notable event by itself but, if not fixed soon enough, might lead to the idea that the owners don't care. If that's the case, eventually another window gets broken or some graffiti is painted on the walls. Later, it spreads throughout the entire neighborhood. The criminality rate starts to raise and the community collapses. A dramatic scenario that is quite unlikely to occur if there weren't already hidden tensions beneath the peaceful surface but the point is that, if an issue is left unfixed, things are much likely to start degrading exponentially. Imagine a car parked in the street. It can stay there for months left untouched but, once somebody breaks one of its windows or punctures a tire, the car is soon vandalized: all windows are broken, beggars start using it as a place to spend their nights, all valuable parts are stolen and it becomes a wreck in no time.

Smaller scale, personal life, common example: it is easy to wash the dishes immediately after dinner but, once you leave them in the kitchen sink unwashed, new dishes will start to gather there and it will be more difficult and unpleasant for you to wash them. A dirty car, uncompleted jobs are just the same. It is easy to maintain things in proper shape but, once you loose track of them, they start to multiply and then it is more difficult to put them back in order - with really bad possible consequences: lack of motivation, depression, loss of productivity and a sense of incompleteness, affecting your mood, your job, your relationships.

In software development, sloppy code maintenance can lead to disaster. It all stars with the inability to enforce coding rules or standards, a too permissive architecture and a lead programmer that does not validate code - either because he / she is too tired, under too much pressure or just doesn't care. Failure to maintain a good code quality is a clear sign that the project is slipping and every programmer will start hacking his way through the source or impose his personal view on things, leading to bugs and spaghetti code. Once this state of things installs, it triggers an acute loss of motivation in every team member, the feeling that the project is loosing track that, in turn, leads to a great decrease in productivity. People become unhappy with their jobs, soon fights start to happen and some might even start looking for something else. Again, a snowball effect.

Points I'd like to make:

• Little things can get amplified and have really bad consequences if not properly recognized and managed.
• Problems left unfixed generate a feeling that "no one cares" and weight that will, eventually, lead to bigger problems.
• Taking care of issues when they first manifest is the easiest way to stay fit.
  

The subject is somehow analyzed, among other very interesting topics, in "The Tipping Point: How Little Things Can Make a Big Difference", written by Malcolm Gladwell - published in Romania by the "Publica" print house.

An interesting article on the subject is also "http://www.ambiguous.org/robin/word/brokenwindows.html"

Montreal

I've just returned from one week in Ubisoft Montreal where I attended a conference on new game technologies. However, I will not write about the conference itself, but about the city and the people I met.

• The architecture - downtown is a mixture of modern skyscrapers, art-deco, Neogothic cathedrals, Victorian houses, new and old, American and European at the same time, that blend together splendidly. In 2006, the city was recognized by the international design community as a UNESCO City of Design, one of the three world design capitals (wikipedia)

• The parks - huge parks, with free ice rings. One of the most beautiful is the Mount Royal, with wonderful panoramas to view the entire city.
  
• The people - a mixture of nations and cultures. In the street, people are warm and willing to help you. The services are great. Everyone seems to do his/her job with passion and dedication.
• The hotel - Ryatt Regency - warm, American, with a light jazzy feeling.
• The streets - traffic seems by far lighter than in Romania.

In a word, a great experience.

Why Sometimes Less Means More?

May sound like a contradiction but, actually, it is not. Maintaining less things or activities around you helps you keep your focus on what is important. It helps you use your entire energy to do only the most crucial things and do them better. Switching tasks is time consuming and energy inefficient. It can also get you depressed because you just don't get to reach your maximum potential in any fields - you know you could do "that" better! Simplicity generates a feeling of lightness and that leads to optimism and confidence. Multitasking is great and can help you do more because it allows you to better fill time gaps and also doesn't get you bored but, be careful how many tasks you undertake ;). What to do when you get overcrowded? Delegate, simplify, get rid of things that you don't really need - become efficient and effective. Too many activities will get you lost in details and you will loose the big picture. When you feel it's just too much, stop, think, reanalyze, reorganize.

Innovation

One of the key ingredients that pushes a company or a product in the elite group is constant innovation. This applies to game development more than anything else because, in this industry, the winner takes it all and seldom it happens that a game that is not innovative sells.

How do we generate innovation, then? The process is tightly linked with a small resistance to change. It can only be embraced in a team that has constant improvement and self challenge as its core values. Innovation appears in teams made of professionals who are involved in the project beyond their current task. Innovation comes from inside those who spots a potential issue and propose a solution - even if the proposition cannot be applied directly, any idea, if spoken, can generate a cognitive process in someone else that might lead to something. It is a rare resource and it should be carefully managed and highly appreciated. It can be triggered only by sustaining a sense of friendship among the team members. It can be triggered by inviting team members to speak even if the subject is not necessary tied to their job description.

Constant brainstorming is a key process but innovation also comes from inside everyone - inner motivation and personal initiative being its traits. As lead, one should always take care people are not afraid to speak their thoughts. Innovation also comes from respect and the ability to actively listen to others - those who think too highly of themselves are less creative because they stopped listening. Everyone should know that their opinions are taken in consideration seriously.

Innovation needs time and, most of the time, it is an iterative process: an idea leads to a prototype, then again and again and then to the final product. People should have time to think and understand their role and the project, and, as a result, it will lead to something novel. However, care should be taken not to get lost in an infinite creative loop and never finish ;)

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)