Saturday, January 31, 2009

Why I Like My Job and The Gaming Industry

a) It's truly dynamic. Technologies change, evolution is very fast and one has to be very competitive in order to keep pace
b) It's highly challenging and fosters creativity and self improvement. It's like living on the edge. In order to stay in the field you really have to be number one
c) It's a vast domain. It's not only about management, programming or methodologies. It's also about what is fun in the world, about how to make people enjoy themselves, about military technology, submarines, weapons, airplanes, warfare, usability, player psychology, mythology, history, beauty and art. It's about cutting edge hardware and various development platforms and constraints: PS3, XBOX, DS, PC, iPhone, etc
d) It's international. Ubisoft, for instance, has studios allover the world and it is possible to work abroad for some time if you really want to and you're good
e) Everything being so cutting edge is also about promoting the right people
f) It's because imagination is really important
f) It's because it's damn hard

Being Agile

Being agile means focusing on features and the product as a whole. Being agile means to iterate and, after each iteration, have a working version of the product. Being agile means to deliver predictable value on the short term and act with the client's priorities in mind all the time.

When presenting Agile (Scrum) to programmers one of their main concerns that rise up is that their code will become spaghetti in no-time and that too much time will be used for changing what has been done. The general perception is that they need do hacks now to deliver an increment and then clean up the to deliver the next increment which means loosing a lot of precious effort. It seems so at first, but what is wrong with re-factoring? Yes, hacking is bad but hacking something quickly as proof-of-concept and have the designers test it quickly can eliminate a lot extra work needed to polish something that may be thrown away. And yes, once the proof-of-concept is validated, management expects the programmers to ask for time to clean up their prototypes and turn them into fully working, state-of-the art pieces of engineering that is then merged with the main development branch.

a) Agile starts from the premises that specs change over time and that the client is free to change his mind anytime after an iteration. This means that is very likely that the feature we try so hard to make room for will not be implemented after all, and that it's very likely that another feature will be requested that breaks the initial architecture. This also means that you need to make your code modular and flexible and be ready for constant refactoring. Good specifications means good enough to start working with and good architecture means something very simple that allows you to build modular code. And then clean it up!

b) Preserving the teams constant over time ensures that that the product is known and understood by everyone. The team takes full ownership of their code, cherishes it and keeps it tidy because, after all, they are the ones who suffer first if it becomes unmaintainable (then comes the whole product as it cannot be delivered on time, then come the customers that may receive poor quality as the result). Since the code ownership is shared across a small team, peer-reviews are constant and, if a culture of constant refactoring is in place, the code actually becomes better and better as new features are added - instead of constantly decaying.

c) Scrum is a tool that allows programmers to keep their code tidy and clean. It guarantees that during the sprint no one will interfere and that they are free to do their job as they see fit. Traditional models allow leads to randomly assign tasks, change specs all the time, in a word create chaos which is the prerequisite of hacks and unmaintainability.

d) Working in small teams leads to better understanding of the source code and knowledge sharing. Code becomes more uniform and has increased quality because more people work on the same areas, share ideas and help each other. Teamwork also minimizes the danger of having some programmers that are the only experts in some areas of code, just because they were the only ones assigned to those areas ever.

e) Traditional models have the risk of loosing track of what the project is all about and get lost in technical details. It is easy to loose a great amount of time developing some sort of cool technology that everyone is very proud of that, from the client's perspective, has very little or no value at all. Especially during the "technology development" phases clients, become very nervous and anxious because they have little visibility of what happens and they see no apparent progress. Therefore boxing technological changes in fixed term sprints increases client's confidence because he/she has at least some sort of deadline visibility and the illusion that that black hole that eats his/her money will, eventually, end soon.

More on this some other time :)


A leader is someone who is capable of developing a solution for a given problem and be able to do whatever is necessary to implement it. He must be able to act with courage and with the company values in mind. He must always have a proactive, optimistic attitude but should also be pragmatic in terms of risks and plans. He should genuinely believe and always make sure that his personal interest is in line with that of the company. He should be able to motivate people and have enough people skills as to make others follow him not by the means of force but by good will. He should be able to convince people to trust and follow him and not let them down. The role of a leader (formal or informal) should always be a positive one – he is the one who makes things happen.

Thursday, January 8, 2009

A Jack Welch Story

The following story is allegedly attributed to Jack Welch and, therefore I will presume the same.

A manager comes to Jack to ask for help in a delicate matter. Jack joyfully offers his assistance but warns his subordinate that the next time he/she comes in with a problem he/she will be fired. "Why?", asks the employee stupefied. Jack answers: "You are hired here to solve problems not to report them to me. It may happen that you ran into something that you can't handle by yourself but such a problem is unlikely to occur more than once in your career here so I'm more than glad to help you. But if it happens more than once though, it means that you are not that good and maybe we can find somebody who does better."

While Jack surely is quite radical in his approach, he has a good point. A manager who goes to his superior whenever he encounters a more difficult situation is a weak manager. He/she has no intrinsic value on his own. Leadership comes from the ability to solve problems and not forward them up the hierarchy. I'm not implying that he/she should hide things or be afraid of consequences of his own actions. I'm not implying either that he/she should never ask for advice or even help. What I'm saying is that, if he/she always feels the need to go "upstairs" for interventions than he/she should seriously ask himself/herself - "Am I really adding value to the enterprise?" And one more thing: if you need to go to your superior, BE PREPARED! Make sure that you have all the answers to all the questions, that you have perfect arguments, discuss them with somebody first. Otherwise you will only make a fool of yourself.

BTW, (Jack Welch in Romania)

Tuesday, January 6, 2009

Knowledge Transfer

Knowledge transfer, information and change should be communicated in a way that will not trigger people's natural defense mechanism and resistance. Ideally, it should be demonstrated by practice and coaching and introduced gradually (however, that is not always possible). The process should also have a human, personal touch. Bombarding people with documents, links, articles, plans is a dangerous way to go. If too much information is presented at once, especially in an impersonal form (email, for instance), it never gets read or understood and, a priori, is considered a threat or something that is worth resisting to or, in most cases, a useless managerial caprice. Change is easier to implement if the team is prepared in time, by sending those documents way in advance and request comments on them, by talking about the advantages and issues, by asking questions to identify possible threats and bottlenecks (no, you don't know everything and everyone has a valid point of view), by fostering learning and identifying and naming issues with the present setup. Talk, be personal, ask, understand what others are saying and remember that knowledge transfer should always be bidirectional.

Monday, January 5, 2009

Debate Invitation: Design Documents Versus Mock-Ups*

I'd like to argue that user interface mock-ups, fake screen-shots plus annotations and verbal stories are, most of the time, a better design tool than spreadsheets, word documents or functional diagrams. While there are other valid arguments for / against them, I find the following rather strong and applicable to a wide range of possible scenarios:
  • One of the main requirements of any software package is usability. The interface should be simple to use and intuitive and therefore, after a mental movie and a mental proof of concept are created and some ideas scratched down, developers should proceed with it right from the start. If the concept cannot be easily fit in a fake screen shot, then there might be something wrong with it. If the mock-up is not explicit enough by itself (and some side, contextual, annotations) then it might be too complex (and difficult to understand and use) and should be rethought.
  • A UI mock-up provides an early feedback on whether the design is consistent. In the process of making the mock-up, one usually reviews its whole mental movie and his/her design notes and tries to blend them together in an accessible format. This way, elements that don't fit very well or don't provide enough value are discovered sooner.
  • A mock-up is by far a cheaper validation tool than a full implementation, allowing you to spot a lot of the possible issues, very early in the process.
  • A mock-up can be a great starting point for a debate or a brainstorming session.
  • Unlike functional diagrams, mock-ups usually do not contain implementation hints. The construct is based only on what the user / player sees and, therefore, allows the programmer to choose the best architecture possible without any algorithmic suggestion. What I've seen is that programmers tend to take design specifications as architecture specifications, blocking opportunities for extensibility, clean code, better algorithms - UI Mock-ups are a step away from this danger.
  • Mock-ups are simpler to grasp and provide better visibility to the design intentions.
  • Product validation is easier to do when testing against a pre-made mock-up. It's there or it's not there - more difficult to forget features.
  • Nobody likes to read lists or long documents. If ever read, long docs are read superficially and, again, some details can be lost and never get implemented. Such a missing feature is hard to discover during validation.
  • Most of the time, lists and other types of documents have to the reader a different meaning than that intended by the designer (nobody understands exactly the same thing and everybody ends up with another mental image of what's required). If mock-ups are not on the paper, they are constructed differently in everyone's heads, leading later to arguments, difficult and costly implementation changes and frustration.
  • The process of verbally explaining mock-ups triggers ad-hoc brainstorming sessions and clarifications. Communication and knowledge transfer is fostered as is friendship among team members.
What do you think?
* by UI - mock-up I mean a user interface design suggestion or a fake screen-shot of some relevant in-game (in-application) element or moment, polished to some degree

Blog To Follow On Agile Methodologies

Here is a blog to follow:

Some highlights:

10 Principles of Agile Project Time Management:

The 12 Best Questions for Team Members:

Professionalism = Knowledge First, Experience Last:

Kano Customer Satisfaction Model: