Live, Think, Challenge Yourself

How I Passed the PMP Exam

2012-01-21T18:57:00.003+02:00

Why PMP?

From my perspective, a credential such as the PMP has tangible benefits that can be divided in two main categories: the recognition of knowledge that comes from passing the exam and the process of becoming a better project manager by learning for the exam.

The PMP credential means that one's experience and knowledge of project management is recognized by the standardizing body (the PMI), giving the owner international credibility.

On the other hand, learning for the exam itself has a strong transformational power. It forces the student to mentally walk through a series of scenarios and relive past projects to understand what went right and what went wrong then. It takes all the previous experience and knowledge and benchmarks it against standardized best practices, recognized across all industries - The PMBOK. I've mentioned experience: to qualify for the exam itself, one needs at least three full years of project management practice*.

How does the exam look like?

It is a computer based, 4 hours / 200 questions exam, which is taken at a Prometric site. There is no official break. To get a flavor of how it goes, one can check many resources online that provide test samples. Here is an example:

http://www.oliverlehmann.com/pmp-self-test/75-free-questions.htm

The exam is not very difficult yet it is not easy either. Beside a good understanding of project management philosophy, it requires concentration to correctly identify the problem, then to identify the right project management process that the problem is part of. Besides that,

Some questions are very long and difficult to read.
Some questions have very similar answers.
Some questions have may seem to have all the choices correct.
Some questions have unnecessary information.
Some questions may pose more problems and the student is asked to identify what is the most critical to be solved next.

During my learning, I realized that it was a very thin balance between answering the questions correctly and wrongly. A mere interruption as small as going to drink a glass water for 5 minutes resulted in a higher probability of mistake that spanned across roughly 10-15 questions (10-15 minutes). I made this measurement over many tests by identifying clusters of wrong answers around the same time I had an interruption.

How did I study?

1. I picked a less professionally demanding period (after the first patch of Assassin's Creed Revelations PC was released) - November - December last year 2011.

2. I enrolled in a PMP class here. Fortunately, they had a session in December. The course itself was based on the Rita Mulcahy method, which I warmly recommend.

3. Roughly 3 weeks before class, I started reading the materials (The PMP Exam Prep book, by Rita Mulcahy).

4. I took 4 working days off of work just before the class started, to finish the book and the exercises it contained.

5. I went for 4 days in class.

6. After the class, 1 week - no learning. During this period I paid my PMI membership, completed my application, submitted it and then, after it was approved, scheduled the exam.

7. After that, for one week, I did 50 questions a day from each knowledge area. At the end of the week I took a 100 questions sample PMP exam. For all these, I used the PMP Fast Track software, also from Rita Mulcahy. This was between Christmas and New Year's Eve.

8. For 4 days after the New Year's Eve party - nothing.

9. 3 days before the exam, I passed through the PMP Hot Topics Exam Flashcards. It took 2 days.

10. 1 day before the exam I took a full 200 questions PMP Exam to see where I stood.

11. On the 8th of January 2012 I passed the exam.

Suggestions for taking the exam:

1. Reading the materials prior to class was of extreme importance. That way, I was able to solidify my knowledge and identify gaps by asking the teacher all sorts of questions.

2. Exam questions are asked from the perspective of a large (100+ people, 1 year+, 1 million+ EUR) international project. Having experience managing this kind of project helps.

3. It helps a lot being in a less demanding period at work.

4. Overstudying does not help, nor does taking the exam lightly.

Good luck! :)

Note:

One insight I had while studying for the exam was that project management knowledge alone was not enough for one to succeed. Strong industry experience is also required to become an accomplished project manager.

PMP(R) Certified! :D

2012-01-08T18:17:00.000+02:00

Few hours ago I passed the PMP(R) exam. Tonight, party! Hehe! :)) :D :D

Champagne! :)

Performance Appraisals

2011-12-22T14:37:00.000+02:00

I believe it is important to evaluate performance not only based on absolute results, but rather on results put in the context of that person: what was his level of understanding at the moment for which we are evaluating him, his know-how, visibility, what kind of help did he receive, how was the team he worked with. Given the context, would he have been able to do better? Is he willing to learn from past mistakes? Did he have the proper means to act differently? Many environmental factors are not under the direct control of the employee nor does he feel he has control over them. Did I, his manager, do enough to provide him with the tools to take the right decisions?

Some people shine in a certain environment only to fail later when the factors they relied on change. Do we take this into consideration? Do we allow them to fail to grow or do we leave them to be failures? In order to perform, one needs to focus on strengths rather than weaknesses and learn from mistakes. What kind of example do we set when we evaluate performance? Do we apologize for our mistakes? Are we really encouraging trial and constructive failure? What do we measure? We should never forget that the performance appraisal is one of those moments when managers show their true self: what they value and what kind of behaviour they expect from their teams.

Appraisals should be done from the heart, with true empathy. It is a very much needed and powerful moment that can affect employees for years to come (in their career path, self esteem, salary revisions, role in the company, perks). It can give them wings or it can break their wings. How much heart and care do we put in that moment? How much responsibility do we take for that moment? Do we try to level people or do we set them performance targets so that they can surpass themselves? Do we customize the appraisal to the individual and his strengths or do we try to fit everyone in the same measures? Do we work toward a Gaussian distribution for performance or do we give recognition and celebrate uniqueness? Do we really care for our men to give them feedback way in advance for them to have a chance to improve before the official paper is signed? Do we explicitly set individual performance targets that can, eventually, be exceeded?

Performance evaluations can be painful if not properly performed. They can impact morale and careers for years to come - even a lifetime. They impact salary, mobility, advancements, perks, assignments, everything. This is why we should care more about giving our guys an honest, customized feedback and set up correct performance objectives for the next appraisals rather than to look good in the eyes of our supervisors. We should try to deliver bad news in advance, verbally. We should try to give people time, space, guidance to improve or surpass our expectations. As Jack Welch put it, a good appraisal is one in which no one finds anything new.

Transactional Thinking vs Generosity

2011-10-31T10:30:00.002+02:00

My feeling is that too many people enforce too often and too soon transactional patterns in their relation to others and their needs. By "transactional pattern" I mean a conversation that can be summed up to "if you do this, you get that".

Even if the balance seems right at first, in many circumstances such a transaction may have a demotivating, un-involving effect, diminishing the trust between the two parties.

The opposite would be to offer generously, not expecting anything in return (or expecting very little), assuming the risk of some taking advantage of you, but building relations in return - not to mention the feeling of fulfilment that comes from giving. From the receiver side, I remember my strong feelings of respect for the people that offered more than I asked for, unconditionally.

While transactions mean insurance, generosity can be seen as a risky investment in others. By giving a helping hand unconditionally and showing trust and appreciation for other's needs and personality, we raise the bar for development and commitment. While some will take what they were offerend and never look back, others will take the challenge and become better persons themselves, giving back or giving forward to others in return.

This brought me thinking back to a book I read several years ago "The Generous Man: How Helping Others Is The Sexiest Thing You Can Do" which argues that generosity is one of the most revealing signs of strength one can show.

Tools And Perpectives On Time Management

2011-10-09T09:49:00.002+03:00

Saturday, Alina held a seminar on time management at the British Council, in Bucharest. I was invited to talk about the tools I use and about my perspective on the subject.

The why's of time management:

Freedom
Productivity: accomplish something of value by staying in the flow
Peace of mind
Time to learn and think - secure your future
Focus on the important

Contents:

The tools I use.
Scalable vs non-scalable. Take time to think.
Some pictures from the event.

The tools I use:

I prefer tools that give me the freedom to work from anywhere anytime and that are well designed (easy to use, simple, very good performance, nice looking). The idea is to gain time by focusing on what I want to do rather than on the "how"'s, and to leverage the moments of inspiration. For everyday use, I find very useful:

- Evernote

- Google docs

- Google calendar

Always connected. I prefer tools that have the ability to sync across multiple devices: iPhone, Windows desktop at work, my Mac at home, the Mac I use in Kyiv. They give me the freedom to work and spot opportunities wherever I am, whenever I choose, without having to carry a big luggage with me - most of the time, the iPhone should be enough.

I want my data with me all the time, yet I don't like carrying it around. Luckily, in the world of today, it is easier than ever to have access to my important documents from anywhere; much easier than it was 3 or 5 years ago. Because of the interconnected devices (phones, tables, laptops, desktop computers), hard drives and local storage are technologies that fade out in the past, in favor of the new cloud model. Cloud or web-based applications allow me to travel light yet instantly take notes whenever something interesting crosses my mind.

Usability and beauty. I like to be surrounded with easy to use hardware and software so that I can focus more on the "what"'s instead of the "how"s and spend more time in the flow. I also like to be surrounded with things that look good and feel right. Beauty is important as it makes work more pleasurable - the environment where I spend my time, my computer, my phone. Simplicity, beauty, usability, speed are all in the same pool of features that make my day brighter.

I don't like to be surrounded by too many objects. Complexity makes life sluggish. It stops me from focusing on the important.

When I have too many objects, applications or documents to manage, I waste time. Being disorganized wastes time and frustrates me. It is much easier and less time consuming to maintain order when I have only a few things around. It gets me productive, helps me stay in the flow, reduces the activities I have to perform. Simplicity is key to focus for me.

Take notes. Remembering stuff is extremely time consuming and inefficient. I gather all my thoughts, ideas, plans, in a note taking app (Evernote) or in a calendar to be reminded later. I see that stress comes from trying to remember what I have to do. If I keep the list only in my head, the only thing I accomplish is to be stressed that I will forget something. Taking notes keeps my peace of mind. Fortunately, today I can take notes anytime, anywhere: my iPhone, my laptop, my computer at work are great devices to sketch ideas for future review. And if I have them all interconnected and synchronized, then I am not bound by location.

Plan your week. A powerful tool I use is the calendar - it helps me plan the week ahead and also keep track of the activities I want to perform. It allows me to free my mind to execute what I have planned - the important items on my checklist - and eliminate the noise of urgency. A hidden advantage of the corporate calendar (Outlook) is that, if I plan my work week ahead using it, I can add there my own free slots for meetings, thus securing non-interrupted spans of time for important tasks. Also, having the week ahead organized in advance helps me say NO - another very powerful tool for managing my activity. Having a plan makes it easier for me to understand why say NO and explain it to the people around me. Of course, like any other tool, planning is useful if it is used on a regular basis.

Although I am a huge fan of communication technology (I have 2 phones, facebook, linked-in and twitter accounts, at work I use instant messaging, emails, etc, etc), I see technology as a double edged sword: on one hand it simplifies communication yet, on the other hand, it makes people consider that others are always available to interruptions. Answering all the requests on the spot, although rewarding in terms of instant gratification, have only the result of fragmenting time and put me out of flow - google "why work doesn't happen at work" on TED. Also, it places me in the "urgency" spot, in reactive mode. This is why sometimes, in the evening, I get home tired yet, when I think back, it seems that I have done nothing relevant that day. Managing interruptions is part of the time management routine and it is very important for me to consider flow when I plan my day.

Scalable vs non-scalable. Take time to think:

Very few people are constantly aware that consistently increasing their output does not come from working more but from working smarter. Ask yourself "if I want do double my value on the labour market, is it smart to work twice as much or find a different way of doing things that would allow me to work the same amount of time but produce twice the result?" That is the difference between scalable and non-scalable.

Many jobs, like ditching, are not scalable - that is, of course, until someone invents the excavator which renders every professional ditcher obsolete. Today, the hunt for scalable is fiercer than ever, as we need to be more productive, smarter, faster, more creative.

For managers it is handy to ask people to work more because it is something that can easily be measured - it can produce some foreseeable results NOW, whereas investing in planning, brainstorming, learning and thinking ahead for each member of the team are more difficult to estimate in terms of practicality. However, on the long run, working long hours daily does not generate a boost of productivity - maybe only a 10% increase which, for sure, does not sound at all impressive.

Why this talk? Because the underlying purpose of time management is to get more stuff done which, in terms, is linked to finding time to think deeper, learn more, search for new ways of doing the old in more productive ways. Time management is about making your work become scalable.

Many people say "I don't have time to plan or learn". Well, they don't because they are caught up in urgency. Ask yourself: how valuable is the work you do NOW? To whom? Is it really needed? Does it really matter? I believe that, because of frequent interruptions, emails, poor planning, a lot of the work we do is useless as it only creates noise, generates chaos and bad decisions - in a word, waste.

Plain execution is not scalable unless it is done by a machine and not a person. For the average employee, he or she simply cannot work twice as long as there is no daylight time to do so. Important is to work smart and say NO to the unimportant so that he or she can concentrate on adding true value.

Execution takes large amounts of time, most of the time underestimated. (I've heard "it is easy" so many times that I just can't believe it anymore). The best advice I could give someone, is to SELECT HIS EXECUTION WISELY and make sure it is, indeed, the most valuable thing he can do. To do this, she needs to think and learn - to reinvent her job.

People expect us to do some factory-style labour all the time because it is something that we are used to see. School teaches us to be busy and it surely is tempting to think that this is the easiest thing to do to increase productivity - work more. This is the "factory" culture and we need to find a new frame of mind to scale our work.

Today, perfect execution is more important than ever. The polish and quality needed to create products that sell is obtained through intellectual sweat and long hours put into them, in addition to passion and knowledge. I am a huge fan of perfection when it comes to execution. Learning also comes from doing and communication is extremely important although it adds another layer of complexity. So pick your battles wise, so that most of the effort is put in the right place. To do this, one needs constant thinking, planning, learning, reflection - to actively manage his or her time.

Some pictures from the event:

Alina Buzatu, my host and trainer at this event held by Empower

Myself, discussing the subject

Showcasing some tools: Google Calendar and Evernote

Small Things You Can Do To Keep the Nature Clean

2011-09-22T20:47:00.000+03:00

Last weekend: short escape in the Bucegi Mountains with my girlfriend, Alina.

View from the road to Piatra Arsa chalet

Unfortunately, the closer we got to easily accessible places of interest, like the "Babele" chalet, we were stroke by the increasing number of beer cans and plastic bottles that were thrown away in the field.

Gathering Plastic Bottles, near the "Babele" Peak (1st round)

Many people think that either a solution cannot be found to having tourists not throwing garbage in the fields or that it is not their responsibility to find a one. I don't think so.

Plastic bottles left behind by tourists

Probably most people believe that it lies with someone else, like with authorities that should increase penalties for garbage disposal in non-specifically arranged locations, have enough law enforcement officers in the field to apply the law, install trash bins in these areas and collect the garbage frequently. NGOs. Students. Army. Somebody else. And up to a point they are right: authorities should maintain public spaces clean, as we pay them to do so and it lies within their area of responsibility.

Others simply don't care.

Plastic bottles gathered from the fields, near the "Piatra Arsa" chalet (round 2) - unfortunately we couldn't carry more with our bare hands

What is often forgotten is the role that each individual has in maintaining the environment pristine. It is within our grasp to have an attitude. Yes, I believe in the power of small individual action applied on a large scale. I believe in the power of small personal effort multiplied by a large number of people:

When you see a plastic bottle thrown down in the grass or in the street, collect it. Collect as many as you can. Other people will see you and might do the same. Yes, I honestly believe that many people don't know that they can collect these bottles.

Invite others to follow. Many people are afraid to make the first step. Show them that it is ok.

Explain what you are doing. Explain the power of collective action. If 10 people collect 10 bottles each, that is 100 bottles - a clean field, without much hassle. 10 people is very few for a location like "Babele" where hundreds of people go there every weekend. Explain the power of personal example. Spread the word! Take a stand!

When you see someone throwing a cigarette on an empty bottle in an un-arranged location, approach him, look him in the eyes and ask why. (yes, it is scary at first, but what would you do if that person throws trash in your own garden - yes, the streets, the mountains, the parks are our own collective gardens)

View from the top

I believe that many people are reluctant to act because they don't trust that their effort has an effect on the long term. But it does and it extends beyond their mere action. I believe that cleaning up the environment is contagious and invites others to follow. It passes the message further. It creates waves. It creates a trend. An individual, by himself, does not have enough power to clean up the whole planet. But he can empower the people around him to do so by his personal example. If 10 people watch and follow him in the course of his life, and if another 10 people follow each of the 10 people, we have already 111 people cleaning up our fields, our neighborhoods, our streets. And it grows exponentially. And where it is clean and tidy, it is less likely for others to throw trash back in.

Tourists at the "Babele" Chalet - if each of them would pick one bottle...

Yes, I believe that it lies within our power to act locally. It is scary at first but after that it feels great. Don't wait for the weekend. Tomorrow, when you see a plastic bottle on your way to work, pick it up! You do it in your living room, right? Why not extend to your street, your nearby park, our forests?

Entrepreneurship - Notes

2011-09-03T17:28:00.002+03:00

GRASP Start-up Weekend - Bran (July 2011)

Here are the notes I took while participating in the GRASP Start-up Weekend meeting this July. I believe they apply to any person looking to take control over his or her (professional) life, not only to those who we commonly refer to as entrepreneurs. For instance, one can have an entrepreneurial spirit in pro-actively managing his education, his career or act as an intrapreneur by employing resources from an organization to develop new ventures inside it. For me, all of the elements below define a free, action and growth oriented spirit.

http://www.facebook.com/MyGRASP

Location: Bran, Romania
Participant profile: entrepreneurs looking to starting their own business
Speakers:

Adrian Amariei - Founder and CEO Axonite
Dan Dimancescu -Honorary Consulate of Romania in Boston
Ovidiu Sandor - CEO ModaTim Investment S.A.
Simona Baciu - President "Happy Children" Foundation, Cluj International School
Andrei Cretu - Manager, PwC Consulting
Iulian Carciumaru - Manager, PwC Consulting
Livia Radulescu - "incubaAT" - UNDP Romania
Cristina Visinoiu - PR Expert, UNDP Romania

1. What kind of profiles does a business need?

All three:

Entrepreneur - breaks the rules, risks
Manager - predictable improvement
Administrator - keep it working

As nobody is perfect, always work with people who are better than you at least in one area.

2. What does an entrepreneur need?

Know people - Network. (HBR Article Here)

Stay up-to-date to spot trends and generate creative ideas. Creative ideas come from associations of two or more domains (transportation and IT, for instance). Talk to people (conferences, trade associations, on the street). Ask questions. Exercise the "creative" muscle by spotting problems around you and try to fix them.

Books
Trainings
Masters
Read the news! My list here (of course, I don't have time everyday to check all of them :) ):

Business plan:

More than a business plan it needs a market analysis (simple: Google, ask for information and feedback wherever you go. Test your product before you do it). Niche! Segment market!
Start slim. Favour contractual relations:

Don't have employees
Don't have co-owners
Own 100% as long as possible
Worst: 50%-50% due to lack of decision power

Write your business plan like you want to sell your business
Elevator pitch - brief and clarity of ideas
Don't overestimate revenue and don't underestimate costs
Write then get feedback - test it before you implement it
Bring an idea from outside - if you can copy, don't reinvent the wheel
Define your product, your market, your network, your selling and your growth strategy
Don't stick with the business plan but have it handy as a baseline

Credibility:

Most important: business today is done based on trust
Built in time
Who is your mentor and who is your advisor? Board of trustees.
People you want to know always talk to you when you are a student. When you are in business, they think you want to sell something - the true value of an MBA is access to these people.
How to build and maintain credibility:

Keep people informed of what you do. Send emails from time to time to cultivate relations, not necessary to ask for something.
Send information that might be useful to them
Say thank you
Reply immediately to emails and phone calls
Send emails to people after you meet them

"Tell me what you have done and who you are associated with and I'll tell you who you are".

Money:

Cultivate relations with bankers and lawyers.
More important than a refusal is to know why you were refused. Ask for feedback.
Sources of money:

Personal funding
Angel investment
Venture Capital
Banks

Think big and global:

How would it transform your business by growing it not by 30% but by 1000% or 10000%. Bringing ideas to the extreme reveals marginal forces and ideas one may not take into consideration. Forces prioritization.
The world is not only Romania or Western Europe. It is also USA, the Arab countries, Russia, China, India, Japan, South America, Africa. How can we extend to these countries? Distant worlds may need my expertise more than the people around me.

3. Personal traits:

Self disciplined

Curious. Quick learner.

Writes ideas down - get into the habit of writing down everything you think about. Plan your week, plan your day, plan your next year. In writing. Write names. Calendar meetings and activities. Ideas. Catalogue sources of information.

Thinker and doer - think first and prototype quick. Rework. Incorporate feedback. Prototype and deliver something fast.

Who are my early adopters?
Who can benefit immediately? (company / person)
Develop in collaboration

Courageous

Passionate

Forward thinker: how can this concept work without me?

Servant mentality: not what I want to do but how can my business help others? This gives purpose which, in terms, helps people self propel in times of hesitation. It helps define the mission which, in terms, is the goal for strategy and tactics and a major motivation factor. Who are we? - What is my motivation? Leader = agent of change.

4. True value of an MBA:

Understand the language of business
Know and network with business people who wouldn't talk to you unless you are a student
Create mental models for reality checks

And since we also took pictures there, here is another one:

Bran, Romania

What Means to Be Sure of Yourself

2011-09-03T14:12:00.003+03:00

Yesterday I was putting my papers in order when I stumbled upon some notes I wrote during a leadership training I participated in few years ago. It was about what it means to be sure of yourself. I thought I'd share them with you as a short sum-up of the subject.

A person sure of herself:

Speaks loud and clear
Expresses his feelings
Expresses her wishes loud and clear

An unspoken wish does not exist.
An unsure person is afraid to express his wishes because of fear of criticism or refusal.

Knows how to say NO

Personal note: I've discovered that it is much easier to say NO when you are prepared. By that, I mean you know your objectives and you have a course charted to accomplish them. If you have a plan, it's easier to estimate your resources and availability and whether what you are asked to do benefits you as well.

Is capable of criticism

Positive statement + criticism
Express emotion + criticism
Express solutions + criticism
Descriptive and precise

Reacts positively to criticism

Criticism is seen as information
Asks for more details and rephrases to make sure he understands
Asks for advice
Expresses her emotions when critics is overwhelming
Can decide whether to use the other person as mentor

Allows himself to make mistakes

Any mistake is seen as an experience that can be overtaken
Any mistake does not say about me that I've embarrassed myself forever

Is capable of asking for help

Only the strong ones ask for help
Hiding a weakness and not asking for help attracts attention

Is capable of self-presentation

Visual contact, distance between individuals, movement, speed of speech, loudness of speech, content of speech

As a side note, all the above traits transcend the One Minute Manager's story:

http://www.amazon.com/Minute-Manager-Ph-D-Kenneth-Blanchard/dp/0425098478

Books That Shaped My Last Year

2011-08-29T19:28:00.006+03:00

I thought I'd share with you some books that shaped my view of the world in the last year (2010 - 2011). It's not only the book that mattered, it's also the moment when I read it so, here is my personal perspective:

Most mind-shifting:

	Agile programming philosophy. Emphasis on intrinsic software quality. Test driven development. Shows what it means to be a professional programmer and to see your profession as a form of art that you have respect and dedication for. Continuous improvement. I read this book in a period of soul searching, while coding for HAWX 2, few months after SH5 release. It really got me thinking about how to build intrinsic quality in our products and how to support my colleagues to not compromise when it comes to "clean code" and bugs. Here on Amazon
	Probably the best management book I've ever read. Focus on intrinsic quality, continuous improvement, respect for people, engineering led organization - here are the principles. To put it in a few words, "The Toyota Way" is more than management - it's a philosophy of work rooted in a deep respect for the human being - the engineer inside the organization, the customer, the supplier and even the competition. Here On Amazon
	The GROW coaching method. Inspiring. Art of asking the right questions. Trust in people potential. Strong leadership model. I knew before reading this book that imperative management style is not suiting me nor that it produces good results in creative teams. I had no idea, though, on how to proceed. This book gave me a jump-start, courage and a tool to be a more people oriented manager, not only in attitude and mindset, but also in practice. Here on Amazon
	Personal development, personal leadership. From inside-out. Collaboration,Win-Win, Synergy, Proactiveness, End-in-mind, Prioritize, Listen and understand. For me this book meant putting into words a series of unstructured thoughts, patterns, behaviours that I intuitively felt were right but I didn't know how to define or explain them. On the other hand, it helped me understand some wrong behaviours that I had, like not knowing how to act in a Win-Win fashion. Reading it, felt like a big relief. Here on Amazon

Other mind-shifters since September 2010:

Tribes - Seth Godin

In simple words, what it means to be a leader. Am I a leader? Reading this book got me thinking about this question, porting me from yes to no and back several times.

The One Minute Manager - Kenneth H Blanchard and Spencer Johnson

A simple pattern for being a high performance manager.Goal settings, praising and reprimands. A very short must read for anyone (manager or not) - 2 hours at maximum. Has some very funny explanations about the formal appraisals and the average mentality that is so common in corporations.

The World is Curved - David Smick

My introduction to the global world of finances. This book gave me some very cool insights on the current financial crisis and on how the entrepreneurial world is financed and by whom.

If You Are Clueless About Starting your Own Business - Seth Godin

After reading the "The World is Curved", I wanted to know more about entrepreneurship. That combined with my girlfriend working to start her own coaching business, led me to getting this book. It took me through all the steps of starting a small business, from writing a business plan, testing the market, creating a marketing strategy, financing or finding a mentor to selling and growing your business. Short, very insightful, useful both as an overview and as a practical framework to follow when you take the big step.

Superfreakonomics - Stephen D. Levitt

I had fun reading this book. If I were to compare it, I'd compare it to Blink, The Tipping Point and The Outliers by Malcom Gladwell (one of my favourite thinkers and writers) - the same kind of example-based explanations.

The Inner Game of Work - Timothy Gallway

Again coaching, from the creator of professional coaching. More philosophy oriented than "Coaching for Performance" but, nevertheless, a must read. A nice and practical theory about how, sometimes, conscience blocks performance and how coaching can help removing these mental barriers.

Clever - Rob Goffee, Gareth Jones

I've never had any doubt that truly creative spirits need the resources of the larger organization, a space in which they can prototype their ideas, that they are rebellious and that they hate management for imposing restrictions on them. Therefore the manager should position himself/herself in such a way that he/she can actually provide visible value to his team in order to gain their trust and cooperation. In short, this is what this book is all about, with examples from Google, Microsoft, EA, Apple etc, etc.

The Myths of Innovation - Scott Berkun

THE tool to use when the team doesn't know what to do to generate new ideas and everyone is hoping for divine intervention.

And some literature, for the heart and soul:

The Fall of Constantinople - Vintila Corbul

I actually visited Istanbul after reading this book. Absolutely lovely and full of history.

Musashi - Eiji Yoshikawa
Quo Vadis - Henryk Sienkiewicz
The Agony And The Ecstasy - Irving Stone

Life of Michelangelo, a deep dive into the mind of a creative and passionate person.

John Maxwell in Romania

2011-03-26T14:39:00.009+02:00

I had the great opportunity to participate together with some of my colleagues from Ubisoft (thank you, Ubi!) to the John Maxwell's conference, "How To Be A R.E.A.L Success". John, an amazing speaker, described in simple words powerful truths about what it means to be successful. The conference was hosted in the Romanian Palace of the Parliament and over 1000 people attended.

Here are my notes from the conference:

- R.E.A.L stands for: Relations, Equip others, Attitude and Leadership.
- Recommended reading: How to Win Friends and Influence People (Dale Carnegie)
- A great free resource: A Minute With Maxwell - everyday a few words about leadership.

Relationships:

Treat other people the way you want to be treated (Golden Rule); always treat people fairly.

Winning with people: people can trace the failures or successes to the relationships in our lives.
Working with people - more challenging than working with equipment.
Who we are determine the way we see people - don't try to fix people, fix yourself. People see me the way I see myself and the way I see them.

The elevator principle: some people lift us up, some people leave us down. Am I taking people higher?

People that lift us up encourage us.
In the life of other people you are either a + or a -.

People practices:

Remember names! The sweetest sound for someone's ear.
The first 30 seconds rule: call by name and say something to connect with the other person (something positive).
People don't care about what you know, they care about what you care.
Law of buy-in: people buy in to the leader before they buy in to the vision. Sell yourself first.

Add value to people:

Add value -> influence -> leadership
If it's lonely at the top, nobody is following you - leaders take people with them because they value people.
Add value means: knowing and valuing what people value; walk slowly through the crowd.
Listen, learn then lead.
In the process of running a race, the leader never wins. He is where the people are.

Grow yourself!

What am I doing to develop myself? Am I growing?
Success is not automatic!
A successful life is an intentional life.
What am I doing to develop other people? Success = teach, train, mentor, coach.
Those who are closest to you will determine the level of your success.
In the history of mankind, nobody did it alone.

You have to like people and have the desire to help them.
Leaders discover their strengths first.

Equip people:

Work on their strengths.
I don't work on my weaknesses because I am weak at my weaknesses.
People don't pay for average. Successful means ABOVE average.
What are my strengths?

Help people find their strengths.
Help them understand success.

The secret of success: the daily agenda. What do I do daily?
Everyday: preparing or repairing.
Discipline. Prioritize.
Take good decisions then Mange your decisions. Follow through daily.
Rule of 5:

Everyday (even on Christmas, even on my birthday) what are the 5 things I do everyday? What are MY 5 things? Discover my strengths!
John Maxwell's: Read, File, Write, Ask Questions, Think.
Secret of success: the daily agenda.

How to prioritize my life:

Requirements
Return of investment
Reward

How much time and money am I investing in my own development?

Attitude:

Successful people think differently; I have fallen much more then I've succeeded.
When I fail, how do I respond to the failure:

Learn?
Leave my failure?

Learn is the way.
It's easier to go from failure to success then it is to go from excuses to success.
Change before you have to! Fall forward!
Successful people don't stay down. Attitude is a choice. The attitude you have in your mind today you have chosen.
The only person in the world to make me happy is me.
Attitude is not enough. Competence is needed. If you don't have the competence but you have only a good attitude, you will only be happy when you're fired.
It is not true that if you believe it you achieved. If you believe in your strengths you will achieve it.

Leadership:

Successful people lead themselves and lead others.
You can grow and learn to lead.

Tools: leadership coaching, mentoring.

AIESEC Bucharest Training

2011-03-20T09:47:00.006+02:00

Yesterday, I had the unique pleasure to speak to the AIESEC students during a training on how to become a true leader. My topic was about how to employ coaching techniques when leading teams and I sustained it as complementary to my girlfriend's speech, Alina (she talked about one-on-one coaching fundamentals and practices, from the perspective of a professional coach (link in Romanian) ).

Here are my slides - thank you Google for the images!

The main, undeclared, purpose of the presentation was to get the participants to understand the attitude that a coaching manager should have toward his team - that is to feel 100% that he/she is part of the whole and that there is a strong interdependence between him/her and each team member.

Empowering Organization

2011-03-18T13:26:00.008+02:00

On an additional note, the longer the command chain from the upper management to the people, the more managers will try to find a way to justify their power positions and the more the people from the lower levels will be demotivated and will take less risks. The organization becomes stiff, focused on processes and conformance.

In an empowering organization, the command chain is short, people from the lower levels of the hierarchy come with suggestions, ideas, improvements that are passed upwards to higher management which acts upon them. After all, engineers know best what is capable from the technology they have at hand, have ideas on what should or can be improved, designers and marketers know more about the latest trends on the market and thus know how to innovate in their areas, and so on. Competitive edge lies in the hands of people who are passionate, eager to perform and have the power to act upon their knowledge. From this comes motivation, trust, commitment, involvement, attachment, and self fulfilment.

How does an organization become empowering?

First of all, it all starts with a company culture that has trust in their own strength and is willing to trust its workforce. From such a culture emerges a trend to focus more on strategy and future and let go the control on people. Management then focuses on improving the processes and removing the impediments from the face of their men and women, so that everyone can concentrate on what they know and love to do. Instead of giving directions, managers will ask their people how they can help them achieve higher performance. People will feel that they have the power to control the outcome of their work and will want to prove that they are up to the trust they are given. The more they have control on their own work, the more they will get aware of what their impediments and limitations are and they will want to improve on that. A creativity and learning loop is then created that propagates throughout the organization - better products, happier workforce, more innovation, better processes, better strategies, more awareness and more involvement.

Instead of having one brain working for the entire team to define what each one does, you have the benefit of having 10-15 brains working all together and cooperating. This comes from trust and it is all ignited by a culture in which people have faith in each other, have the power to define choices and choose for themselves, a culture in which manager's role is to propagate awareness and communication throughout the organization. Unfortunately, it takes a lot of courage for an organization to change as the process of changing a culture is painful and will trigger a defence reaction in most of its employees who may feel that their security and privileges may be compromised.

Building High Performance Teams

2011-03-18T12:52:00.005+02:00

Building a high performance team: (quick ideas)

a) Create a safe environment where people can express themselves. Empower engineers as the main driving force of the project.

Define expectations and roles. Management is a role and not a power position. Respect.
Management manages processes, not people. Create the true sense of interdependence.
Involve everyone in decisions that affects them and the project. Let the team define its goals and objectives.

ACB Bucharest core team in Kyiv to help move ACR there

b) Make sure that commitments are respected. No matter how small they are. Agile planning is a great tool for this.

Plan in iterations. Adapt. Communicate. Make sure that, in the end, no debt is left for the following iteration.
Honest failure is OK and safety is restored through re-planning.
Visibility and clarity on common goals.
Celebrate successes.
Management is fully involved in respecting the commitments it makes.

c) Build a learning environment. Learning is rewarding and involving. It increases cohesion, communication, commitment, involvement.

Encourage learning. Learn from everything.
Promote initiative.
Safe, enjoyable environment. Management is part of the team. Always. Common goals.
Increase knowledge sharing, encourage diversity of thought and know-how.
Increase productivity through new, innovative ways of doing things. Challenge the way things are done. Agree with the team on common variables to measure improvement. Celebrate improvement.
Discourage repetitiveness. Encourage lateral thought.

Always respect a) if in b), a) and b) if in c).

Agile Planning

2011-03-15T12:42:00.001+02:00

Getting more agile:

In a word, agile methodologies are about acknowledging at the most inner level that change happens: http://agilemanifesto.org/ and http://www.AgileManifesto.org/principles.html

Agile methodologies still need planning. After all, I doubt that many commercial software projects are started without at least a partial visibility on the budget and the scope involved. They need a vision, a goal to reach for and the steps to get there in order to convince.

These methodologies welcome and favor change and their practitioners are not afraid to modify plans if needed. The tendency is to keep things simple and manageable, keep the team happy and focused for undetermined periods of time and minimize risk on quality through constant releases. Stakeholders are informed about what happens in the project by directly experiencing the results, rather than getting through tons of reports. Yet still reports and accompanying documentation may be needed for proper understanding, but the focus is on the product.

In a sense, the planning methodology described in a previous post has agile traits. Early planning is kept to a minimum, refinement is achieved throughout the course of the project, flexibility in terms of vision and features exist. It's just that we need to go beyond that and add new elements to get where we want: high quality within budget and a happy, proud team.

Improving processes and optimizing workspace:

First of all, let's start by ripping off the authoritative aura of the traditional manager, making him part of the team and adding him a new role: that of the facilitator. His/her goal when acting in this role is to find creative ways to improve team performance by removing obstacles and clearing the path ahead. Let's quote from the agile manifesto:

"At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behaviour accordingly"

Then, let's add some means to find out what the blockers are: the best I could find (yes, it was not my idea;) ) is to have a daily 10-15 minutes meeting to find out what the current problems are and have people discover if the problem is local to them or more common. The purpose of this meeting is to create an urgencies agenda for the day:

• Action plan for the manager
• Find out who has encountered the problem before, if any, and gather some quick suggestions
• Schedule more detailed meetings with people that manifest interest in the problem, after this meeting completes
• Celebrate success when the project advances
• Update the plan - where we are, where we are going

Software development and management are continuous, iterative processes of self improvement. While the goal for the agenda is noble and visibly useful (and fun), the actual meeting may not succeed from the first. It is important to keep the goals in mind, have patience and iterate. At first, it may become boring or too long but, as experience grows, it should get more and more successful and to the point. Just like anything else, the process is under continuous scrutiny by the team and suggestions for improvement should be made and always taken into consideration.

A second meeting should be considered; a longer meeting this time, one hour for instance, scheduled once a week or two, to discuss how we can improve and streamline our activity on a more macro level. While the daily meeting usually touches hot subjects, blockers that have just appeared, the longer meeting should take the form of a coaching or a brainstorming session, where more subtle issues can be discovered and action plans are laid to overcome them. Ideally, this meeting should be lead by a more experienced person or set up at first under less stressful periods so the people will be more eager to iterate.

Quality enforcement:

The second level of transition from the normal waterfall method to agile should be the quality enforcement. We need this because, in order to gain approval, we need success stories fast. We need a build that gets visibly better. People should feel first hand that something has changed such that, instead of focusing on putting features in as fast as possible, we now shift our attention to details, quality and, thus, self-esteem:

• Bugs have a higher priority than features.
• Quality is enforced early through smoke testing (daily builds) and code review. Additionally, the dev tester should be called in to verify the feature before check-in as, if the daily build fails, this is a dramatic event - part of the team may not work!

To have this, we need two prerequisites:
• A working pipeline and a daily build process that is checked continuously.
• Visibility, like play the version once a week, an hour, in an organized manner, with an emphasis on new developments.

The most important aspect of development is to keep the version clean and working smooth. This has higher priority than anything else and all the team should focus on this and find ways to improve and secure the daily build.

Planning in a more agile way:

Planning is a little bit more tricky because it has to deal with uncertainty. I think it should have three levels:

1. Macro level should contain top level components, with allocated times and budgets. Unlike imperative planning, where tasks are assigned and fixed, this level is maintained as a general baseline, a guideline for communication and for risk estimation.

2. Second level is created by adding user stories. User stories are the requirements. Their scope ranges from "the game should have a crew management system with an interface" (along with a rough estimation) to "when the player clicks on the crew icon, it should change colors". These user stories should have a time estimate (given by team) and value (given by the requirement owner) and they become more and more detailed over time, as implementation moves forward. They can be changed or deleted easily.

3. Refinement is done by the team, in a planning meeting, before the iteration begins. The team chooses what to do in the iteration based on the value and the dependencies of each user story. Then, each story is split into tasks.

Agile planning should be an on-going, forward looking process. User stories should be detailed ahead of the iteration so that, when iteration begins, the team knows exactly what they can commit to. Important: 1st step to develop a team: make everyone stick to their commitments fully, no matter how small they are. This increases self-awareness and self-pride.

Hosting the Public Speaking Support Group Meeting

2011-03-12T22:16:00.002+02:00

Today I had the pleasure to host the Public Speaking Support Group meeting held at the Orange Concept Store, in Bucharest (thank you Razvan Daba!). It was an incredible experience to be among friends and listen to their presentations about what they love to do.

Here are the slides I used to support my intro to the meeting. I hope they will give you a hint about how cool this project is (Romanian).

BTW, the project is open to anyone! Looking forward to meeting you!

Team Building Exercise

2010-12-27T15:50:00.005+02:00

Here is a small exercise that can be done during a team building, with the following purpose:

Increase team cohesion and trust
Identify a set of common strengths and weaknesses as well as opportunities and threats to us, as a team
Get the pulse of how happy people are with what we do everyday: job and personal fulfillment
Identify a set of blocking beliefs and find ways to look at things from a different perspective
Identify an area to improve until the end of the project
Setup a SMART objective and make a plan to achieve it, that we can intertwine with the project schedule

Team buildings are great opportunities to discuss other topics beside the day to day activities because they provide the location, time and relaxation needed to touch deeper subjects like "happiness", "growth", "connection". I think that only by bringing these subjects to the table people can identify common concerns and glue together as a team to plan and overcome difficulties. Only by talking openly there is a chance that work, life quality in the office and meaning will improve. Of course, actions must be taken but, initiating the talk is the first step.

Christmas Charity

2010-12-05T11:02:00.001+02:00

Casuta cu copii | Promote your Page too

An initiative by two of my dearest friends: Razvan and Corina.

It is about bringing gifts (footwear and winter clothes) to poor children in an orphanage in Bucharest.

Charity really happens

Planning

2010-09-25T14:14:00.090+03:00

Compromise sticks and spreads

Nobody wants to write poor code or dig through it, yet, somehow, it happens. It all begins with a requirement or a prototype that needs to be developed fast in order to obtain a validation. Management and designers like it, it hits the deadline. You are congratulated for your success. Up until now, everything is as it should be. This is how prototypes should be developed.

Then a new requirement comes. "Wait! I've only created a quick hack!" But the prototype works and you've already been congratulated and the second deadline is coming fast. You promise yourself that you are going to fix it as soon as possible, but the very day that you check-in, you and other people start adding layers after layers over it and change never happens. It could be that the feature is perfectly engineered and polished at first but, as new code is added on top of it, the original is never truly reworked, so it slowly starts to rot.

The project becomes more and more difficult to maintain and grow. Morale gets down, quality gets down, and productivity gets down, self esteem gets down, will for self improvement gets down. Some people even leave their jobs. Even if some teams actually start by cleaning up their previous mess and bring again the code to a better state, it is a onetime process, that happens only once in a few months or years. Being a one time, massive scale endeavor, the result has high chances to only end up as a different mess.

When one makes a compromise, it sticks. And then, another compromise is needed to cover the previous one. Debts start to gather in and, in the end; the debt is so high that one realizes that he/she will never ever cover it. And the process keeps on going and accumulates more and more debts, until everything becomes so expensive in terms of money and people that we need to throw everything away and start again.

Why?

I think it all has some simple root causes:

People develop in isolation. They don't talk so they don't have the chance to unite for quality.
No code reviews.
No frequent informal verbal exchanges.
Rigid planning, commitments to feature lists instead of quality.
Bugs are not fixed immediately as they appear and, instead, are postponed to "debug periods", and often scheduled only at the end of the project.
Interruptions of any kind.

Lack of communication and rigid planning make prototyping lose its core purpose, as it is perceived as feature complete when it is merely a quick proof of concept. Developing in isolation makes it difficult for people to say "STOP, we need to change this" and management never truly gets to the bottom of problems to fix them.

Do we really need to start from scratch?

A very good friend said to me yesterday that, in nature, something has to die in order for a species to evolve. But how does this translate to software development? Does this mean that we need to start from scratch in order to evolve? Always?

I don't think so or, at least, it should not happen unless a major technological breakthrough occurs that renders everything else obsolete. I believe that software needs only to be released in order to evolve. It needs clean, frequent releases and then it needs mutations. We, programmers, call them "refactorings". I will stress this again: in order to evolve, software needs to be cleaned up before the release - no debts to the next iteration. And we need a culture that embraces change and mutations.

Beside internal clean-up, these releases should also reach their customers (editorial teams, designers, beta testers) in order to get their feedback and adjust the feature list for the next iteration. A release without customers is tough to justify (close to pointless) and it's a pity to put in so much effort and not take the opportunity to do some user testing. After all, evolution needs feedback in order not to generate monstrosities.

To sum up, a healthy development process should accommodate short term iterations consisting of:

Detailed planning based on a roughly detailed feature list
Actual implementation; communication among developers, peer reviews
Debugging and stabilization - no debts for the future, all bugs are fixed
Sign-off by QA
Release to customers for feedback
Communicate status, negotiate features and deadlines, incorporate feedback, and discuss how we can improve the process so that the next iteration gets better.

Managers don't manage people

Another thing I realized, no matter how shocking it sounds, is that managers don't manage people. They manage processes. People buy in and start adding value or they don't. You can assign tasks but you can't really force anyone to complete them. Therefore, the notion of "motivating an employee" makes no sense, really. He/she is either motivated or not. What you can do, however, is create an environment that appeals to the employees, so they get excited about their job and become productive. And this is the really tricky part.

Quality from the user's perspective

Indeed, the only thing that matters to sales is how the product is perceived by its customer. Nothing else. Code doesn't matter, as it is invisible. Code only matters to the production people. If it is crappy, it ruins the life of the men and women involved in its production. It turns them away from the product, productivity drops, conflict sets in, and motivation goes away. Yet this does not impact sales directly; it impacts everything else.

Getting back to process - Planning

I'll make a small detour from the quality issues to examine planning, as the core activity that drives project to completion. In the following paragraphs, I will present the normal planning method with its advantages and disadvantages and how it can be applied. After understanding planning, I will get back and show how to transition to methods that are more appropriate to ensuring quality in software.

Everything in a project revolves around plans and planning. Planning is a continuous process, plans change as requirements change, conditions change and understanding grows. Visibility and vision is based on plans. Communication with stakeholders is based on the same plans; resources are requested just the same. Commitments are based on plans. Monitoring and controlling is based on plans. Strategies are based on plans. Planning and plans - everywhere. Yet some managers either don't take planning seriously or they don't iterate on already made plans to adjust them. Why?

The answer is quite simple and straight forward (order of bullets is irrelevant):

In the early stages of the project making informed plans is really hard and it seems that we can do better off without them. After all, it is easy to get people to do something tangible now.
Some engineers and designers are reluctant to planning as well (especially if they are not used with the process) and managers don't want to deal with this kind of issues up front.
In the late stages of the project we are so busy putting up fires, escalating issues, requesting resources, fixing and dispatching bugs that we can't stop to plan.
Superficial planning is hard to spot therefore allow your plans to be challenged by the stakeholders and the team.
Planning requires going back to the same document, ripping it off and doing it again many times. It's difficult to change everything when you worked so hard on it. Over and over again.
Some feel that planning is a waste of time: things seem to work without plans at first.
Some managers (former star employees) are so used to actively solve issues that have visible impact on the project that, when they are required to stop and think about the future, they feel it is useless. Why? Because to them plans seem to be only coloured excel sheets, without a tangible impact on the outcome of their project.
Planning is a costly activity and some organizations or teams may naively try to eliminate it as waste. Planning is costly because it involves not only the manager, but the whole team or, at least, the most senior part of the team.
If not properly communicated, a plan means a commitment which seems hard to make and changed later.

How to plan?

Here it is: http://www.projectsmart.co.uk/project-planning-step-by-step.html. Easy, isn't it? :)

For starters, I will assume that we already have some visibility on the sales volume, on the budget and on the release date. Let's assume the mandate sounds something like: "We need a project that will generate roughly X units sold and that will be released around the Y date. It should cost somewhere around Z monetary units." I will assume that there is historical information in the company about this kind of project and that the constraints are reasonable. Also, probably most important of all, we have some good visibility on the project deliverables and core features - that means that we are well advanced through Step 1 (Project Goals) and Step 2 (Project Deliverables) described in the link above.

Top-down approach - project schedule:

1) We know the release date and the budget, therefore we can establish quite easily the major milestones and the resource ramp-up (based on historical information, common sense and available technology).

2) Start drilling down and get a list of raw features and core activities for each milestone.

For preproduction (research phase) we allow room for exploration, namely we select few core features (technical and design breakthroughs) that we are going to develop further.

For production, based on the already made list of features and the vision that we have at this point, we create a macro Gantt chart that displays all the major activities, with resources assigned and time frame. This estimation takes into consideration the following: rough duration, rough vision and feature value in the overall economy of the project.

Then, when the actual implementation is soon to be started, PM, design and engineers start refining the implementation so that it fits the allocated budget.

In order to ensure quality, buffers are embedded either inside the activities or/and special periods are allocated during the entire process for stabilization and debugging.

Ideally, the plan should fit on a single computer screen or whiteboard, so that the PM and all team members have clear visibility on where they are and what comes next, by a single look. Also, this coarse granularity allows flexibility for later issues. And let's don't forget that, after a certain level of detail, the amount or work required to reschedule and re-plan can be quite a challenge.

Advantages of the method:

Visibility - great communication tool. Very easy to understand even by an outsider.
Not very hard to develop (it is all based on honest estimates, seen from the top) - yes, the planning itself should be seen as a separate project conducted by the project manager and have all the team and stakeholders involved. Again, keep it simple.
Accurate in terms of feature relevance - more important features are given more time and more resources in the total economy of the project.
The plan is small and easy to track and change.
Mitigates some of the pitfalls of the pure waterfall method, as it allows room for changes down the stream - features are not detailed until close to their implementation.
More important features are put in first.
Dependencies are easy to spot and taken into consideration.
Resources are easily leveled and their need understood.

Possible pitfalls:

Distribution of effort in front of the deadlines (tendency):

Rough distribution of effort over time

(Effort increases substantially as the deadline approaches)

The plan is long term. Even if at one point the team commits honestly to respect the schedule, this commitment erodes in time, especially after problems arise. If the process for re-planning does not involve the team again, some people will feel the plan was sloppy from the first place, some will remain committed to the previous iteration while others will feel that the project is not firmly lead - after all, new requirements are added or tasks are exceeding their allocated time. Even if everything works fine, still the commitment erodes and some will try to break the boundaries. Commitment needs to be reaffirmed from time to time.
People may feel that there is time. Initially the requirements are fuzzy and the tendency is to underestimate them.
People may feel that there is room for sloppiness because of the buffers (especially if the plan is not that detailed). Project is long, we have all the time in the world, and we can afford to be less disciplined. Milestones may be treated with discontent and some may even feel that they are added there only because it's good to have milestones. Again, because of the long time, people feel that there is no real pressure in the beginning. As initial task allocations are exceeded, a sense of poor quality spreads (broken windows).
If iterations are added to plan, because we know how many iterations will be, the first ones may be treated superficially.
Some creative people will invoke the time allocated for tuning and debug at the end to over saturate the project with features. They will always claim there is time for debug, to favour putting features in - (http://blog.alexandrugris.ro/2010/08/software-quality-1.html). Beside the risk at which the project is exposed, this also creates tension in the team.
It is harder to enforce quality bars. Outside debugging periods, bugs tend to creep in (after all, why are the debug periods scheduled unless to fix bugs?!) and, because it is hard to break the time commitments advertised to all stakeholders, project management may feel that the quality is good enough for the time being and that it can be fixed later. Just the same, it is hard to drop features if they were initially incorporated into the plan and some people grew attachment to them.
Even though we try to retrofit the design and implementation on the initial estimate, many times it shows that the original estimate it just too short to be useful.
Feature value changes during development.
Historical records show that, initially, most plans have much more features scheduled then available in the release version. As project matures naturally, the number of features decreases dramatically and focus shifts to bringing core elements to perfection. Rigid plans are an obstacle in front of this natural selection process.
New requirements will appear and we need to plan for them, even if they are uncertain in the beginning.

Some hints to apply (which worked for me):

Clearly state that the plan is “tentative” and that it is subject to modifications.
Allow room for iterations
Commit only to what you know you can respect
Estimate risks on each element
Use it to derive a cut list when delays occur and estimate impact of delays
Detail as you advance through the plan
Release often to customers. Plan for intermediate releases to be used as benchmarks against the plan.

Software Quality (4)

2010-08-28T18:36:00.017+03:00

In my previous post, I started a quick pass through the most common methods for ensuring quality at the lowest level: the day to day production activities. My assumption is that, if we are able to maintain a high level of quality throughout the entire development process, we will end up with a better, easier to maintain product, sustainable over several generations, and, as a side effect, a happier team.

We need to find cost-effective, lightweight processes, that maximize ROI. These processes should, ideally, not increase the number of collateral activities required, but, instead, should provide some easy to implement practices, acknowledged by everyone as valuable. Only by acquiring consensus, coupled with self discipline, they will be maintained when the pressure sets in. I am talking about a way of working that should ensure:

Better understanding of the quality level; clear visibility for everyone of what has been correctly done and what are the current issues
Predictable results
Increased return of investment (see footnote 1)

A healthy development process should also have positive side effects:

Shorter develop-prototype-test cycles (2)
Better spreading of knowledge throughout the team
Increased ownership and pride
Friendlier environment
A better distribution of effort throughout the entire length of the project

Some practices are team-wise, while others are linked to self management and can be employed even without a team-spread acknowledged process (3).

Working outside the product code - a workbench for rapid iterations:

Few things are as annoying as frequent interruptions or uncovering poor quality work that you have to deal with - like digging through messy code that has side-effects. These usually happen in a large code base, that has high coupling between components or that starts very slow. These two symptoms work hand in hand and, I think, are the biggest two impediments to constant re-factoring and team morale (starting slow leads to fewer runs which means less testing and fewer recompilations, which, in turn, means that programmers won't spend time improving existing code and will only add new layers on top of it). On the other hand, small applications have a very short modify-run-test cycle, that allows them to mature quickly and with fewer bugs. However, this advantage is usually lost in time, as the code and data gets bigger and bigger.

Is it possible to maintain the advantages of extremely short iterations over time? One solution that can often be applied is to isolate development from the main product, something that can be done easier especially when coding a new feature from scratch. The main goal would be to eliminate as much as possible the interruptions, by initially constructing a sandbox that (9):

Compiles and starts fast
Allows to write dirty modifications and test them incrementally
Allows to re-factor constantly what has been written, without impacting the rest of the code
Allows to focus only on new code, without worrying about other changes

Such a sandbox should allow very short prototype-compile-start-test-modify cycles. Even one at 2-3 lines of code modified - priceless! A programmer could hack test cases directly into the dev-code and run them tens of times a day to see the effects of his latest additions. He could easily re-factor everything until he is fully satisfied with the results (4):

Code that gets fast prototype-improved cycles matures faster.
When integrated, it has very few bugs because it was extensively tested and went through.
Keeping the development sandbox in sync with future additions permits to quickly check future bugs and ensure consistency in time.
The amount of dependencies to existing system is kept to a minimum. The code becomes self-contained, reusable.
Having more than one client for your code (5) requires that boundaries are well cut an clear. This helps maintain the code clean, as artificial dependencies cannot be created.

Sometimes it is not possible to work outside the main product. Many times, the code has been developed directly inside the main branch and, therefore, the amount of dependencies to other areas is so big that they cannot be decoupled. In the rush of development, it is very easy to create artificial links and not maintain clean cuts between modules, just because there is no system in place to enforce these boundaries. After all, it compiles! (6)

When developing outside the main branch, this kind of borders are naturally enforced by the development system, thus they cannot be crossed easily. However, if the development sandbox is not kept in sync with future additions and boundaries are not enforced further, dependencies will start to spread and the system will start to decay (7).

Test Oriented Development

In my previous paragraphs, I basically described an approach that resembles somehow to test driven development (TDD). It allows programmers to develop their code in separate applications (or test cases), iterate fast to get results fast and then integrate when ready. If these test cases are run and maintained throughout development, the benefits could be even higher as they require that the code is written in a modular fashion, they serve as test-bed for new features and bug-hunting and, equally important, they can be used as an entry point to understand functionality.

I will not get into more details regarding TDD, as I have not practiced it first-hand beyond what I've described above, but I think that great attention should be put into integrating automated testing during the production phase and, equally important, to find a framework and a state of mind within the team that fosters quality at this level, even in times of great pressure. Sometimes it may seem like a chore that tests need to be maintained as well but, at least from my perspective, it is easier and cheaper to maintain tests or develop functionality outside the main product then to dive into unknown, hacky code, that has side effects and unexpected links to other obscure areas.

Some may argue that this kind of test oriented development is not suited for all sorts of tasks and I agree. From what I've seen, however, I believe that greenfield development can be isolated from the main branch at least in its initial phases (be it UI or network or anything else). And, although the initial phases have passed, why not try to keep this isolation further and also maintain the sandbox in a working state? It can be used as a priceless testbed for future development and regression testing.

Other disciplines need fewer interruptions and rapid prototyping as well:

In order to spread the benefits of rapid iterations, the team should foster the development of such tools that require that the designers, programmers, artists restart the game (or the product at large) as few times as possible as fast as possible. The best development tool for a designer or for an artist is that one that allows him to see his work directly inside the engine, live, as he performs his changes. This would allow him to prototype as much as possible, ideally continuously. It is essentially the same need that programmers have regarding their code. Example of such tools include editors that have accelerated, game-identical, simulation capabilities, live connections to 3DS Max, tuning tools that connect to the running game, live editors. The shorter the produce-export-test cycle is, the more time is left for iterations and more time the team has to creatively play and improve the product.

On the other hand, a lot of bugs appear because, during frequent changes, something is lost on the way. Very useful are the tools that automatically validate integrity before the asset gets into the game. The more checks the better and, therefore, such tools should be developed and spread to other teams as well, reducing implementation cost through sharing of technology and knowledge.

Similar processes to TDD should be implemented in the art and design departments, to ensure fewer bugs at release time, less overtime and a clearer picture of where the project stands. Activities that support high quality also help spread the knowledge and reuse of existing and well tested modules. Code / asset reviews, tools that verify content, tests, using 3rd party APIs, creating sand-boxes, may seem, sometimes, as to provide an additional burden, but in the end, if applied wisely, should decrease effort, decrease costs and unleash creativity.

Sum-up

The more iterations the better the product has the chances to be. The lowest level at which a developer can iterate is the source code or asset production. When people iterate very fast, they can try new things, have less fear of failure and their work product is better tested and crafted. Even more, the productivity loss and frustration associated with going in and out of flow is diminished. Coupled with discipline and peer reviews, constant iteration and continuous testing is key to attaining high quality, both during day-to-day activities and, at a higher level, feature and product-wise.

Implementation

Although sometimes difficult to see from the developer's seat, a healthy development process has the tendency to accumulate value as it rolls on. I assimilate positive practices to a snow-ball: they are difficult to establish in the first place but they grow in value faster and faster as the team acquires more and more success stories (8).

Some practices will not be seen as valuable by all the team from the very beginning. As such, they need to be implemented in less stressful times, when people are more prepared to try new things. Their value is usually seen in time, after they have become established methods, adapted to each organization. Feedback from the team is very important, as it removes implementation barriers and increases commitment to respecting the new ways. I think that, when implementing such changes in methodology, to understand that there isn't a-size-that-fits-everyone solution. Therefore, management and people should invest time and thought into finding the right way of adapting industry proven practices to their line of work, through collaboration, based on common goals. (Our Iceberg Is Melting)

In the following post I will depart from the code level perspective, and reach into some higher level management frameworks:

Scrum and quality management (two previous posts here)
A process for quality management, that includes test driven development, white-box testing and black-box testing (mixing developers with testers and making testers part of the development team).
Case study: radical approach: one day per week, developer self managed time
Lean thinking
The importance of having all the team experience the product first hand, as its first beneficiaries (play the game!)

Footnotes:

(1) The production cost should decrease, both on the short run and on the lung run, by diminishing the need for suffocating debug periods right before the deadlines and turnover. Even more, remember that 80% of programming time is lost into digging and trying to understand what their predecessors have done. Decreasing this 80% should definitely reduce project costs or allow for more improvements.

(2) Actually, a well implemented quality strategy should have the side effect of prototype-ability. That is, a product that allows new changes to be integrated, tested and removed quickly, without major side-effects.

To achieve that, the number of extra activities that are needed to prepare the prototype should be decreased to a minimum. That can be done only if the code is well understood by everyone: concise, clean and modular. I will not get into the details of what clean code is, but I'd like to recommend two books on the matter: one is "The Pragmatic Programmer" and the other one is "Clean Code". Why clean code? Because no stakeholder is interested in productivity drops or having a product that has sluggish performance or frequent crashes.

(3) One practice I am not talking here about is pair programming. Some of the most rewarding moments I had in my professional life (and also moments of intense knowledge transfer) are related to pair programming experiences I had with more experienced engineers. I believe it should be encouraged as a good practice inside a team - formally or informally.

(4) Just to give some examples I've worked on, that used this kind of approach:

The character animation system from SH4 (together with a co-worker and friend): developed as a DLL loaded by a basic engine viewer. Start-up times? Few seconds. We could easily export animations from 3DS Max to the engine and test our system tens of times a day.

The pathfinding algorithm from SH4 AddOn: I've started hacking a C# GUI app that allowed me to visually check paths on a simple world map generated from game-data, without having to start the game. Again, compilation and start-up times? Seconds.

The AIFramework dll from SH5: hacked as a Python prototype, then coded it in C++ as a dll, loaded by a console application that hosted the test-cases. Restart time? Again seconds.

(5) At least, you have the main product and the application that was used to develop that code.

(6) Thus, even for simple changes like tuning a hard-coded parameter, the programmer suffers a compilation and a full restart, which is a very lengthy process. Sometimes, the boundaries are so poorly cut that even a slight change could trigger a major recompilation. When this cases occur, the only solution is to locally re-factor every time a problem is encountered, thus slowly improving code over time.

(7) Adding scripting support to a project, for instance, could, potentially, bring this kind of benefit as well. Since the boundary is naturally enforced by the compiler, the developer is forced to pay more attention to how he organizes his code. Also, well implemented scripting allows code modules to be developed and tested in an already started application, reducing the compile-start-test-modify overhead.

(8) The not-invented-here syndrome should be avoided at any cost. Good tools are expensive to build and they may not be justified financially if developed for a single project. However, the more sharing goes on and the more projects benefit from valuable technologies and practices, the ratio between initial investment and its returns becomes more and more favorable. Initial development cost is covered by multiple teams and, as sharing is increased, technologies converge and become more and more useful and easier to use. Again, the snowball effect.

(9) This is not conflicting with the continuous integration principle.The idea is to build a sandbox that allows fast prototyping and short modification times for (new) features, integrate when the feature is almost complete and then keep this sandbox in sync with next changes (an example: a new data import / export pipeline should be developed separately while the previous system continues to work and commit when ready and well tested). It does not mean working on an old branch or separated from the rest of the team. By contrary, changes should be presented continuously and designers and testers asked to validate functionality on a frequent basis.

Software Quality (3)

2010-08-25T13:26:00.006+03:00

In my previous two posts (here and here), I've briefly touched some hot subjects:

Quality from the user perspective and how important it is to sales. I've presented some types of issues that hinder smooth customer experience.
Internal quality as a requirement for sustainable product development. I've asserted that customer-perceived quality cannot be sustained for long on a shaky ground.
We've seen a nightmare scenario that could happen if a well defined and rigorously followed quality management process is not in place. I've showed how this could lead to excessive overtime, slowed-down development, higher costs, lower morale, a bill many times paid by future development.
In the footnotes, I've showed that quality is a focus of all true professionals and how true professionals openly discuss and defend their principles.

In this post I will discuss (self) discipline as a basis for building great products and productive environments. I will also describe some practices that the software industry at large uses to attain sustainable quality, thus increasing employee self-esteem and customer happiness.

As software applications become more and more pervasive, penetrating deeply into our lives, so is the increased concern for high reliability and excellent experience. Software market is a very mature place, with a lot of competitors striving to sell roughly similar products to increasingly demanding customers. Concerns with quality began few decades ago, when human life was put for the first time in the hands of software driven machines: think airplanes, rockets, cars, only to name a few. Since then, the talk about reliability has moved to desktop applications, servers, phones - basically, everything you can think of. Of course, the processes needed to ensure bug-free software-driven life support systems are different then those needed to put rapidly on the market a state-of-the-art entertainment application, but they all have something in common: attention to detail, discipline and commitment to excellence.

Discipline:

Maintaining quality is a long-running, tedious process, that demands strength to resist the temptation to bend the rules to finish your work faster. It is very difficult to achieve, as the pressure is high from all sides and the rationale behind sticking to processes is not always apparent and understood by everyone. Even more, the results of applying quality management principles cannot be predictably foreseen, as, if everything goes smooth, no problem arise and people may feel that they spent more work and more money on something that cannot be actually measured. Disaster strikes only if quality is not managed properly, but it strikes later, after glorious results have been shown off and, of course, then, something else can be found to blame. (I use the word "managed" but I don't refer only to managers. Indeed, they should create a framework for people to have courage to defend and encourage the quality of their work but everyone should be held accountable for his/her deeds.)

Discipline manifests in three ways:

Sticking to tedious processes that, at times, seem only to make the development harder.
Taking time to challenge our work and the processes even in times of crisis (Kaizen).
Sticking to your principles and processes even when external pressure occurs.
Working constantly, planning and following plans throughout the entire duration of the project. Indeed, it seems very hard to focus after a difficult ending and when the deadline is two-three years ahead, when requirements will definitely change and people fear their effort will be in vain. It's difficult to explain and find the heart to undertake hard work from day one, yet this is precisely why many projects are delayed, quality is decreased and frustration accumulates. It is very tough, requires thinking ahead, a strong heart and discipline.

In the decades since software management established itself as a full fledged science, processes matured and many companies found ways to ensure enduring quality of their products. More and more, developers become aware of the impact their production discipline has and start to take pride in the sustaining quality of their work, instead of their quick hacks to a local solution. As success stories hit the headlines, we start asking ourselves how they did it.

In the next paragraphs I will discuss mostly from the programmer's perspective, but the same rules can be extrapolated to both design and art and even to project management itself.

Where does the programming time go?

Here is an astonishing fact, that every developer can confirm: each programmer spends up to 80-90% of his/her time not writing code, but trying to understand what he/she or his/her predecessors have done before. Many times he/she fails to understand all facets and introduce subtle bugs.

Digging through sources is, most of the time, a tedious and not rewarding activity. Thus, optimizing by 50% the time spend searching is something that could radically improve life of programmers and has visible results on the budget. Yet this is hard to recognize, because, after spending so much time understanding what others have done, programmers feel the pressure to quickly get out of there by hacking their way to a solution to report a success to their managers (see also The Broken Window Effect). In a culture where re-factoring is not understood, it is difficult to explain why we need the extra time. After all, the results may be even worse and more spaghetti layers added to the already overwhelming complexity. I can even say that full re-engineering of a poorly written module that has thousands of lines of code is so difficult, that we'd better not touch it. Is there an escape? I think so.

Testing and re-factoring:

Some time ago, I read a paper from Microsoft that said that there are only two effective ways to increase quality of code. One is peer code reviews and the other is permanent testing. Many procedures have been created to make room for these and, as time passes, more and more companies embrace test driven development (TDD), pair programming, scrum and other agile methodologies. Even in companies known for not applying agile principles, code reviews executed by peers or by an external audit committee are performed. The outcome of these practices is constant re-factoring. In a word, the code is not left to rot. It is constantly updated and adjusted to the latest specifications.

Is there a point to undertake massive re-factorings at once? I'd be very cautious about that. The risk of getting a bigger mess or exchange one mess for another is extremely high. However, I am strongly advocating constant, small, incremental updates. When a programmer finds something that starts to rot, he must update it on the spot, not hack something else on top of it. This constant improvement will not change the software into something better over night, but will cultivate a sense of pride and a mentality of constant improvement, shifting the focus from hacking. After all, constant improvement is the second most important trait of real professionals after sharing knowledge with their peers. (Anyway, the two are very much linked and roughly two facets of the same trait).

Code reviews:

The vehicle to encourage re-factoring and sharing is peer code reviews. Two or more developers gather in front of a computer and the programmer just about to commit his/her sources explains to the rest what he has done and why he took the decisions he took. Then the audience suggests a number of changes and the code is committed after the they have been made.

It is very important to understand the benefits of code reviews and the programmer not to take it as he is verified. He is not. He just shares to the world his solution and spreads his knowledge. It is a time of joy, socialization and pride. He is challenged on points he might not have thought of. He is challenged to respect coding standards and, by verbalizing his solution while going once again through his work, he, many times, discovers bugs he might not easily find otherwise. (I've experienced myself code reviews and I was surprised to uncover bugs I've introduced, bugs that, otherwise, would have haunted me later when found by QA).

Code review is very powerful but, unfortunately, some people are stopped by their egos to practice it. In the professional world, such egos should not surface but, since ego is a human trait, it should be taken into consideration. Code reviews are not places for showing off nor evaluation sessions. They are fun gatherings since they basically are just a bunch of professionals discussing what they do and love the most. They also create personal bonds and disseminate knowledge.

Regarding the time investment, usually a code review lasts for something between 10 to 30 minutes, when conducted by 2-3 programmers. At an average of 15 minutes, that means 3 * 15 = 45 minutes, 3/4 man-hours. Consider that, if you find a bug in 2-3 sessions, finding it, testing it, fixing it, regressing it is, by far, more expensive, without considering the other benefits (clean-up, knowledge transfer, bonding, which are harder to measure)

Sum-up:

Up until now, we've seen how work discipline is important, what are the most difficult aspects to creating a disciplined working environment but how it positively impacts production. We've also touched re-factoring code, bringing it up to date and code reviews. In the next chapters, I will talk about other vehicles to ensure enduring quality of our products, starting from the base level - the production itself:

Working outside the main branch
The benefits of test driven development (two clients for the same code); white/black box testing
Short compilation and start-up times
Prototype-and-improve cycles
Scrum and quality management
A process for quality management
Case study: radical approach: one day per week, developer self managed time
Lean thinking

GO TO NEXT CHAPTER

Software Quality (2)

2010-08-25T00:37:00.020+03:00

In my previous post, I talked about software quality from the user's perspective. In the final paragraph, I briefly exposed my view on the general framework to achieve such quality - the well known KISS (keep it small and simple) approach to software development.

General Process (statement):

Managing quality on the grand scale is best achieved through:

1) start with a small set of features
2) make sure they form a consistent core
3) implement, adapt, test, polish, bring to perfection.
4) incrementally add new elements; perceived quality comes first (usability, accessibility, wow moments, visual polish); experience is the product.
5) resume from 2, redesign and re-implement as needed. change is good and healthy
6) when the time, the budget and the quality is up-to-par, deliver
7) offer support, talk.

The beautiful part is that quality management scales down from the whole to each of the components, to the very last line of code, design document or model. In a word, you can't cheat quality. You can't have high perceived quality on a rotten core. Eventually, it could happen for one product, but at the expense of future development and constantly increasing development costs. True professionals have a good and pragmatic understanding of quality and take great pride in applying these principles throughout their work. They stick to their guns to defend quality in all its dimensions when challenged* (see footnotes).

In my future posts, I will drill down and see how we can deliver a high quality feature, then extrapolate to the whole project in the form of a proposed process. But, before that, I will refer to a possible scenario, that can happen when quality management is not seriously considered from the early stages of product development - excessive overtime due to not meeting quality standards**.

The problem with overtime due to quality issues:

1) Faulty or no quality management procedure leads to:
a) Product looks better on paper than in reality (everything appears as done yet the project has an unknown quality status)
b) Lack of visibility and a clear estimate of the remaining work

2) Because of the overly optimistic view on the project status, new features creep in. In fact, it is very difficult to freeze development because no solid argument can be given. The papers look good, the project seems to be working and roughly healthy. It is this moment, when the game starts to shape-up, that the designers and artists push to add more and more features to the game, without considering very much the possible inconsistencies***. After all, we still have time to tune an polish and then tune again, right? Not quite!

3) Close to the deadline, as the team moves slowly from features to bug fixing, more and more bugs are discovered. This time usually coincides with the moment when the test team is ramped-up and the product is more and more benchmark-ed against quality standards. Slowly, the real picture creeps in.

4) A vicious circle becomes apparent: more resources are added to the end of the project, effort on integrating new people is unknown and not measured, programmers starts hacking through the code, new and reopened issues rise up, more overtime is needed to fix them, yet tired people make new mistakes and the morale goes down. Although the rate of fixing bugs can be positive and on a very good trend, the hidden code quality is decreasing fast, at the expense of future development****.

An even worse consequence can happen: at a certain point, all development is frozen or heavily slowed down for days or weeks because the build is unplayable and a large part of the team can't work.

Footnotes:

* Through civilized communication, active listening and understanding of all opinions. Professionals think in terms of benefit for the customer, cost, industry standards, future investments, return of investment. They don't think of themselves "I am a professional therefore I know what quality means". On the contrary, they are willing to challenge their current perceptions and improve them continuously. Professionalism means modesty and openness to dialogue.

** Overtime can also happen due to the desire to meet a certain market opportunity when the team willingly commits to some seemingly impossible goals, but I will not refer here to this kind of enthusiasm. Most commonly, however, it is a mixture of quality issues, excitement, not finding what is fun soon enough to fit the budget (in game industry) or other scope management issues, all to various degrees. It can be light - few extra hours, maybe a weekend or two once in a while, or it can be worse.

*** It is normal for this to happen because, now, they finally have live feedback on their creative effort. These guys are very passionate and take a lot of pride in their work.

**** As some of the main ingredients of attaining quality are professionalism, excitement and commitment from all the people, excessive overtime is an enemy of quality. While based on previous records we can estimate the needs for overtime in terms of budget buffers, it is important that:

managers and teams proactively try to estimate and find ways to diminish the need for long hours in the office and keep the project on track early, since the conception phase.
stabilization and debug periods are planned throughout the course of the project, in order to maintain the build as close as possible to "release quality" and have a good visibility on how it is doing.
a process is in place to ensure that quality from the user's perspective is attained on solid grounds and that the project is not rotting inside - quality is sustainable on the long run.

While quality and deadlines are the responsibility of the manager, the whole team should actively participate to meet them. After all, it is a sign of professionalism of all sides involved.

GO TO NEXT CHAPTER

Software Quality (1)

2010-08-24T22:03:00.028+03:00

Foreword:

I start this thread to lay down some thoughts that haunted me during the past period. I would like to convince the reader that quality matters very much, that one cannot obtain customer satisfaction unless industry-proven practices are employed throughout the entire course of the project and that failing to implement solid quality management procedures can have very bad consequences. These consequences are reflected in development costs, sales, trust and can span across multiple generations of the same product. In the end, I'd like the reader to retain the idea that focus on quality is the responsibility of all team members. Some hints will be given on how teams achieve excellence in their work, to their own benefit and that of the customer. I write these posts based on my own experiences, articles, books, discussions with friends who also work in the software industry throughout the world, and some projections I made for the future.

Customer Perceived Quality:

Every (software) project has to maintain an optimum balance between quality, cost and time. Provided that we keep cost and time fixed (which is the case for many projects) we have only one degree of freedom left. We need to understand what "quality" is, in order to know how to properly handle it.

To discuss about quality from the user perspective is to discuss about project scope and the number of issues the customers encounter (including documentation). On the other hand, quality is a general term that encompasses also: internal knowledge (code, processes, graphical assets), internal and external communication, management and the sense of self fulfillment of all stakeholders (team, all parties). On a broader sense I would like to link quality to professionalism and success, excluding the financial part* (see footnotes).

In this post I will refer to customer perceived quality:

Project scope: arguably, but a project that has a higher number of features should provide more usage scenarios and therefore should have a higher (potential) value for the customer (personally I like simple stuff but that is another story).
Broken features ("hard" bugs): features that don't function the way they were obviously designed to function (like crashes or a button that does nothing when pressed)
Design errors ("soft" bugs): features that function according to design, yet they are hard to use, have uncertain value, don't really satisfy user needs, are inconsistent, etc.
Perceived quality - degree of polish, nice touches, attention to detail, wow moments and, very important, smooth performance
Product documentation - should be large enough to cover all aspects, yet concise and easy to read by the target audience - I will not cover documentation here, as it is a vast subject.

If the bare minimum functionality is not implemented, the project is no good. Imagine a submarine without a periscope: it's inconceivable and useless. On the other hand, a submarine crew that has fewer animations than initially planned could be considered acceptable, as long as it is consistent and the number is above a bare minimum to provide some immersion and give a clue of what the crew is doing. In this case, people have a fuzzy understanding of what the optimum number of animations is (of course, the more the better, but more providing diminishing returns) and less animations are not true barriers to functionality (personally, I would choose to have less functions but highly polished. Given the animation example, I would think very carefully if I want this feature at all if I cannot bring it close to perfection).

The key for "hard bugs" is to obtain a low reproduction rate, no game breakers and no fully broken functionality. There is a threshold that must not be passed but, a random crash once in a while (very rare!) is acceptable, as long as the load times are short and no (significant) progress is lost. Also, this kind of bugs are easily caught by the test teams, so they are usually fixed before the release. The least damaging are bugs like those in the "flickering textures far away when the light falls from a certain angle" class. They don't disturb too much, don't affect progress in any way and, as long as they happen randomly, could be considered almost no issue.

Design deficiencies are: inconsistencies, lack of usability, lack of accessibility, crappy functionality that no one understands. Some design errors are quick hacks for a deeper (technical / concept / budget) problem. Everybody knows about them, nobody is proud of them. The second category of design deficiencies is what I call "the elitist design", which is "good core but misunderstood and poorly explained" (at large or by some less experienced players). On the opposite side, comes the "dumb-ed down symptom". Generally speaking, a large project scope fosters design inconsistencies. Some design errors are hard to spot and require extensive play / usability tests. The problem is that the team knows the product so well, that they become blind to this kind of issues. Therefore, external help is needed.

As long as the above deficiencies are kept to an acceptable level and the product has optimum performance in terms of speed and smoothness, small enhancements like flooding inside the submarine, washed periscope lenses, provide real value and increase the perceived quality. On the other hand, easily observable visual or audio bugs, although may not deeply hinder game-play mechanics, dramatically decrease the sensation of quality. Very important, a visible and firm support policy is a certain way to improve perception from our customers.

To conclude, my feeling is that, in order to maximize the quality of a software product, the best approach is to "stay small and continuously polish". This leads to a product that has fewer but better polished features. Keeping the number of elements low maintains a higher degree of manageability and saves time for iterations.

Quality is very expensive yet, today, quality sells. Due to increased market competition, customers are having higher-than-ever quality demands and not meeting them is certainly affecting sales both on the short and on the long run - through tainted image and brand. Due to the ubiquity of the Internet, customers easily create to themselves an image of the project before purchase and this image sticks**. Web pages, reviews remain for years.

As the marketing people say, experience is the product so a lot of effort has to be put into the perceived quality: visual / audio polish, accessibility, beauty, usability, minimum workload for the user. Starting from a small core of must-haves, then incremental enhancements, gives time to perfecting the product. Late cutting results in hard-to-eliminate inconsistencies, panic and, in the end, shipping a less-than-par experience.

Footnotes:

* It could happen that a project that has a high quality standard and its customers are very happy with it is not performing well financially. However, a project that is not meeting quality standards yet is performing well financially cannot be categorized as a success. Cost is only transferred to the next generation, both in terms of perception (brand, company image) and in terms of internal quality (code, documentation, graphical assets, processes, etc...).

** Management of expectations and of communities is more important than ever in the days of the Internet. After all, unhappy customers are the most vocal online, as they find the web as an accessible, wide-audience platform to express their frustration. Managing the product image actively through open communication channels with the customers is a way to ensure that the product is evaluated to its true level and it is not drowned in discontent.

GO TO NEXT CHAPTER

Public Speaking Support Group - Playing Guitar

2010-06-17T20:22:00.007+03:00

Public Speaking Support Group - this Saturday I'll talk about something I love - music. Below, I've inserted the mind map I've created to build my speech. I will support my performance by bringing on one of my guitars and let the participants practice some very simple chords and tunes I'll show them. I'm very anxious to see how it goes. Looking forward to Saturday! :)

(Thanks Wikipedia and Google for images and quotations :))

Here is a picture from the event (added later):

Difficult People

2010-06-08T15:00:00.005+03:00

We, sometimes, have to deal with difficult people during meetings. They show aggressiveness and insolence - or, at least, we perceive their attitude as hostile. It's important to handle these situations up front in order to keep the team intact, decrease the opportunity for gossip and make everyone a little bit happier. It is important to remember that these people may actually have real issues that drive them to behave the way they do, that they believe their attitude is justified and that knowing their issues and trying to solve them could improve the atmosphere in the team. Other people may share the same feelings, although not expressed openly. Dealing with difficult people is also a great way to display leadership and drive by example.

I've sketched a small mind-map (work in progress) for this matter. It briefly scratches the subject and merely shows the attitude (ask for details) one leader might have when confronted with a difficult situation. Here it is:

In the end, it is important to remember that:

Troublemakers may be people who care about the project but feel frustration
They may have issues shared by others in the team
Trouble-making may be a wrong way to attract attention
Troublemakers may give you headaches in the future if not addressed properly early on
The best way to ease them is to give them what they want, while evading the conflict triangle (victim-aggressor-rescuer):

Be heard - some recognition
Change something

It is important to follow-up the conflict:

Results
Ask for feedback if the troublemaker was right
Show him what went wrong and that he may have not behaved properly, although he was right

What do you think? How do you proceed?

Empowering Entrepreneurs

2010-06-01T23:15:00.007+03:00

I'd like to announce a very interesting project, targeted especially towards young entrepreneurs, called Empowering Entrepreneurs: http://www.entrepreneurs.empowering.ro (a project by JCI Bucharest)

The project consists of meetings, held at the "Bucharest Hubb", between participants and the coach Mihai Stanescu. The aim is to help young business starters share expertise, network and acquire new skills to develop their ideas.

Currently, there are 2 sessions planned:

Innovative management methods – 19 June 2010
Practical solutions to develop your business – 3 iulie 2010

but, probably, there will be more.

I have the chance to help on this project (spare-time activity, volunteer work), side by side with some very enthusiastic friends (Alex Gavriliu (http://www.alexgavriliu.ro), Bogdan Borza and Andreea Tanasescu) but we also got help from Giani Cojan and Mihnea Ilicevici.

Update:

Some noteworthy ideas discussed, through practical examples and live coaching:

need for self discipline - exercised through daily routines and commitment to schedules
need for planning (in life and in business)
need for benchmarking against the initial plan
equilibrium and how it can be attained through self discipline
working and always learning and improving

Programming "Don't Forget!"'s

2010-05-20T21:19:00.003+03:00

Because sometimes it happens that we forget simple things, I'd like to share with you a small map of things to remember (and check) for your next (or current) Visual C++ software project. Some concepts are true for other platforms as well, but the parameters are VC++ specific.

The mind map is not by far exhaustive and I'd be delighted to collaborate with programmers or software managers from all over the world to share expertise. Therefore, if you would like to discuss further and, maybe, enhance the map together, I'd be happy to share the XMind file that includes also links to resources on the web.

Taking Charge Of My Life

2010-04-22T18:54:00.017+03:00

Yesterday it stroke me. For a long time I was thinking how to increase my professional performance yet mix it with my personal life, while maintaining this balance on the long and sustainable run. I felt that something had to be done, that I was missing something, some attitude that I could not verbalize.

What I realized is that I needed to take charge of my life and run it like I would run a business. After all, one's greatest asset to manage is himself and his time. Actively managing them, brings up many benefits like:

Always having a clear scope and a target to reach, focus
Taking full ownership and responsibility of what I am doing
Paying attention to all signals around me, actively gathering feedback from everywhere - after all, I have a "business" to run
Feeling more alive, having more energy
Becoming better and better, personally and professionally.

This kind of attitude has reflections everywhere around: being more focused and more present, you inspire others to do the same. It's nothing specific - it's a mindset that makes you strong and confident.

One of the greatest assets of a team or person is ownership - the sense that he/she is part of the project, that he/she cares about his/her work and the sense that his/her performance directly impacts him/her in a positive way. Taking care of your life in a business-like manner, means that you perform everywhere like an entrepreneur. You don't feel that you work for a somebody else, that you obey directives hoping that one more day will pass, but rather you are an agent, work for yourself and have a contract with a company, a contract that you fulfill because it is in your mutual interest. - it's a mindset that cultivates ownership and performance - in you and in others.

This mindset allows one to be responsible of his/her actions and not blame others for his/her failures to act. Being in charge gives you strength and enhances your will. It also forces you to pay attention to what is around you and react fast. This increases optimism and courage to perform.

Taking charge of your life means having confidence in yourself. And having confidence means removing mental barriers and allowing peak performance. It has a snowball effect - personal performance increases your confidence and experience and, as a result, it means performing better and leading your life in a better way. Only benefits. :)

Public Speaking Support Group (+Giving Feedback)

2010-03-20T17:42:00.008+02:00

It was the second time today when I participated in the Public Speaking Support Group meeting. What is this all about? Well, it's about a bunch of people who love speaking in public, who need these skills in their everyday work and who decided that it's time to do something. It's a diverse group, with different backgrounds, from different domains but all with a positive attitude, willing to go beyond "I'd like to overcome my fear of appearing in front of other individuals" and who actually make the step to become better public speakers.

During a session, held in a nice cafe in the Dorobanti area, with wifi, food and very good coffee, several participants stepped forward to present to the others something about them - a passion (like Tango for instance), a project (like Silent Hunter 5 :) ), something they encounter in their everyday job or something that animates them. It's not only about speaking in public, it's also about intriguing topics and mind opening. It's about speaking about what one loves, so all presentations come straight from the heart. After the talk, everyone gives feedback on how it went and also the participant is asked to share how he / she felt.

Today we talked about branding, about censorship, about presentation preparation and about giving feedback. Overall, it's a really great experience, that goes beyond public speaking into sharing expertise, personal development and networking with great and enthusiastic people.

Just to give you an example, today I talked about giving feedback. My presentation was not a technical one - teaching style - but rather explained my view on giving feedback and shared my thoughts on the matter. While I, myself, have to learn a lot about the subject (both in theory, and, especially, in practice) some of the points covered were:

a) Why it's important to give feedback:
- An opportunity to exchange information and build a communication bridge between all parties
- Self development - takes courage and self control to give an honest feedback
- Self esteem - feels good to tell what you think and do the right think
- Chance of improvement, chance of changing things
- Motivation through recognition
- Chance to find solutions not distribute guilt

b) How to give feedback
- Location and attitude (climate of confidence and trust)
- Positive state of mind, free of anger, willing to do good
- Know exactly WHY yo give feedback, what is the purpose
- Focus on facts and behavior and not on persons
- Importance of not being afraid of giving bad news
- Sandwisch technique
- Asking for feedback on feedback
- Balanced feedback

Looking forward to the next session, held two weeks from now in the same cafe, in the Dorobanti plaza.

BTW,
Here is a link to a session that was video recorded a few weeks ago (I was not present then and it was not held in the nice cafe in Dorobanti but it's the only video reference I've got):

http://getaresultnow.com/2010/02/how-it-was-at-the-first-edition-in-2010-of-public-speaking-romania-2010-02-20-orange-concept-store/#more-573

Some Management Style Conclusion at the End of the Project

2010-03-04T16:58:00.010+02:00

• Rebellious spirit – I’d rather have a small revolution when I make a mistake then no reaction. A small revolution means people actually care. I’d rather have somebody to challenge from time to time “the way we work around here” than somebody who always does exactly what I say. Of course, it should be done in a respectful, polite and open manner and everyone be opened to discussion and mutual understanding. It does not mean lack of discipline nor insolence.

• Respect – Nobody knows better than somebody else. Everyone is entitled to have an opinion about anything and should not be criticized for that. We encourage team work. Rudeness, gossip and despise have no place in my team. Criticizing in public a person or an idea is also forbidden. When we judge, we judge facts and not persons.

• Thinking outside procedures – procedures are good as long as they serve the project. When they don’t, they should be dropped. I will never – ever punish someone for stepping out of the rules to try something better.

• Involvement and autonomy – My honest opinion is that everyone knows better than the manager what has to be done in his/her own field. Therefore, fostering autonomy and involvement is the only way to make the step toward great products. Obedience maybe will finish the project in time, but the quality bar will be low, the number of features minimal. I a word, mediocre.

• Encourage experiments and never punish failure as the only way to move forward and allow people to be courageous about their jobs.

• Work environment - play games, natural light, and fresh air – extremely important.

• Fun is made with fun. Involvement is obtained through fun and not through orders.

• Recognition - works much better than punishment

• Whiteboards work better than excel files at sharing information (at least they force you to be concise) – too bad I used them scarcely and only at the end of the project (maybe next time I'll do it better)

Silent Hunter 5 Finally Out! Champagne!

2010-03-03T21:35:00.007+02:00

After many months (years) of hard work, we finally did it! Silent Hunter 5 is out and players all over the world are enjoying the game!

Beta Preview: http://www.simhq.com/_naval/naval_035a.html

A consistent part of the team, the second day after Gold Master

http://www.silenthunter5.com/

Champagne! Cheers to the team!

A very beautiful and powerful community video: (Youtube, search "silent hunter stabizisback")

And on the cover of the Romanian computer magazines:

Looking Back (2009)

2009-12-20T15:22:00.029+02:00

New Year's Eve: a good moment to look back at the year that passed and try to draw some conclusions. A friend of mine said once, "failure doesn't matter, it's only lessons to learn from". I agree with him.

Many people say that 2009 was a bad year, because of the economic depression, because of the shortage of jobs, because of the increased stress. I wouldn't call it bad, but difficult. The optimism that characterized 2007-2008 was harder to find. Many companies changed their strategies and rhetoric, switching from the confidence and growth-oriented speeches of the previous years to cost reduction policies or even lay-offs. For employees, the situation got tense. People are more afraid they may loose their job as management is putting more pressure on efficiency. Tension is floating in the air in many corporate environments. I will not argue here whether this is counterproductive or not, but I dare to say that even though employees are more focused on cost reduction and usually tend to do their jobs more carefully, the amount of innovation and involvement has, somehow, decreased (I read such a statistics somewhere that, based on what I see around me, I am inclined to believe). People seem to have lost something from their excitement about their work as many of them have switched to survival / cautious mode. Everyone is waiting for the recession to go away and to see the labor market flourish again. News reports show that the quality of life has decreased in 2009. Has it or it's just the feeling that something bad is about to come and it's waiting around the corner? While for many it is, indeed, much worse, for others, who may have no apparent reason to complain, the months-long anxiety and the rumors surrounding them seem to have shaped in a negative way their mindset.

Since I am an incurable optimist, I say that most of the anxiety is in our heads and in the way we look at things (Arguably, right? Yes, for sure, and I will, probably, get a lot of criticism for the previous statement). If I take only the facts though, at least in my case, there hasn't been a decrease in the economic level or a substantial increase in the amount of hours I spend at work. I have experienced a lot of pressure though (but I would have probably experienced it in other conditions as well) and, sometimes, it affected my mood and my overall perceived happiness. For me, 2009 has been a year of many changes. Strictly factual, I would characterize 2009 as a moderately good year, because, most of the time, change presented unexpected opportunities (or, at least, it brought hope for the better).

We, as humans, don't cope well with change as it throws us into uncertain territories. We get anxious in front of the unexpected and most of us perceive it as frightening but, if we keep our eyes open and realize that something bad might happen anyway, maybe we could enjoy life a little more. For many, including myself, it is not always as easy as it is to say it, since it means a lot of energy, strong emotional balance, strong will and determination. As the false economic security feeling of the previous years is lost somehow, some turn to other values in life in search of balance and security. Is this good? Is this bad? I don't know and I don't have the slightest desire to debate it here - I guess it's just a normal, human, response to the turbulent environment.

2010 seems to be even blurrier than 2009 so what I wish for myself is equilibrium. I wish to always find strength to pass beyond all obstacles and seize the opportunities that lie past them. I wish to maintain a clear vision about what I want to achieve and have the will to achieve it. I wish that, at the end of 2010, I'll be a better man, more experienced and more knowledgeable, more warmhearted and at least as confident and optimistic as I am right now.

I wish everyone a Merry Christmas and a Happy New Year! May the joy of the season fill your hearts with happiness and warmth!

Disconnected Thoughts

2009-12-08T23:10:00.002+02:00

The difference between a dreamer and a person of great success is that the latter actually does something to achieve his / her dreams.

Focus is slowly shifting from efficiency and order to extreme motivation, adaptability and innovation. Since we need to invent new ways to serve our customers, we need to find those people who are desperately motivated to do it (and keep them motivated :p).

The effectiveness of a research report is inversely proportional to the thickness of its binding - Todd Wilkens (Adaptive Path). I'd extend that to that the effectiveness of any kind of report or document is inversely proportional to the thickness of its binding :D

We are not our target audience! When we build a product, we need to understand the needs, the emotions and the ways our customers are doing things. We are not developing products for ourselves but for a wide range of people, with a diverse range of feelings and backgrounds and we need to see who they are and honestly empathize with them as persons, not as consumers.

Innovation - Random Thoughts

2009-11-03T00:03:00.016+02:00

* You tell me that you are waiting for inspiration? Stop waiting and do something! Grab a pen and a piece of paper to scratch ideas all day long. Think of your current problem with all your mind, heart and soul. Ask someone. Prototype with all available tools. At work, at home, in the shower, in the car. Take a break and then restart the process. Be unsatisfied until you have all the answers.

* True innovation lies outside the boundaries set by rules. But we need rules to organize all the rest.

* There are at least two prerequisites for innovation: a clear set of constraints to deal with and an unsatisfied, extremely curious, always looking for improvement and tenacious set of mind.

* Innovation needs constraints, know-how and will. But, above all, it needs a well defined problem and people who are desperately motivated to solve it.

Book Summary: First, Break All The Rules:

2009-10-27T21:56:00.004+02:00

The following ideas are not mine but they come from a great management book: First, Break All The Rules (a book based on a Gallup study on what great managers do to be so great)

Key Ideas:
1. The best managers reject conventional wisdom.
2. The best managers treat every employee as an individual.
3. The best managers never try to fix weaknesses; instead they focus on strengths
1. and talent.
4. The best managers know they are on stage everyday. They know their people are
2. watching every move they make.
5. Measuring employee satisfaction is vital information for your investors.
6. People leave their immediate managers, not the companies they work for.
7. The best managers are those that build a work environment where the employees
3. answer positively to these 12 Questions:

* Do I know what is expected of me at work?
* Do I have the materials and equipment I need to do my work right?
* At work, do I have the opportunity to do what I do best everyday?
* In the last seven days, have I received recognition or praise for doing good work?
* Does my supervisor or someone at work seem to care about me as a person?
* Is there someone at work who encourages my development?
* At work, do my opinions seem to count?
* Does the mission/purpose of my company make me feel my job is important?
* Are my co-workers committed to doing quality work?
* Do I have a best friend at work?
* In the last six months, has someone at work talked to me about my progress?
* This last year, have I had the opportunity at work to learn and grow?

Procedure

2009-10-27T10:54:00.005+02:00

Procedure: a tool not a purpose!

As manager, I try to encourage people to solve problems and think outside procedures. If a procedure doesn't help solving a problem, maybe the procedure is too rigid and maybe we should think more carefully about it. Maybe it needs an update.

Management Creed

2009-10-14T00:38:00.010+03:00

One of my main priorities as a manager is to develop people. I'm striving to create development opportunities for my team, to help them become better professionals, better as humans, better in communication, more organized and more effective. I wish all feel that our project is in line with their personal development aspirations. Only then I can obtain the 110% we need to finish within impossible constraints. I wish I never disappoint my colleagues, to be honest and fair no matter what the consequences, not to make compromises, care deeply for them as humans beings, with feelings, needs, hopes and dreams. Many times I fail to get that 110%, but then I know I've made a mistake somewhere - not in my creed but in my deeds.

Silent Hunter 5 Announced!

2009-08-17T23:55:00.012+03:00

http://www.subsim.com/radioroom/showthread.php?p=1152450#post1152450

http://www.silenthunter5.com/

Great one! :D

Suggestion

2009-07-15T00:32:00.003+03:00

Give people confidence and a tough milestone. Prepare the safety net and be amazed by the results.

Comments on Not Asking Questions

2009-07-09T13:13:00.007+03:00

Most of the people don't ask questions they think will put them in an inferior position or damage their image because they feel they should have already known the answer. Why? A better approach is, I guess, to understand that if you are a pro than you are a pro and people see and respect that in you or, if you are an aspiring pro, then the easiest way to become one is to learn - and people respect that also. By restraining oneself from asking, one gets to:

Not get relevant answers.
Consider many things to be understood a priori by all parties involved because "real pros already know all these simple things" - Do I need to say how wrong that is? How all people see things differently because they had different experiences?
Miss ideas, suggestions. All unspoken words are a missed opportunity for lateral thinking.
Be considered uncommunicative or, sometimes, even worse: arrogant or stiff.
Understand things the wrong way, get wrong ideas, do wrong things.

I guess that, if one is in the room, probably he/she is there because someone has confidence that he/she has something to say so why not say it?

VERY IMPORTANT: no to fall to the other extreme: speak all the time because you think you have all the answers and have the right to monopolize the whole conversation. The point for asking questions is to let others speak and gather information from them by actively listening to what they have to say.

Thoughts On "Cannot Be Done"

2009-07-02T20:55:00.011+03:00

We are valuable for what we can do and not for what we can't do. Before jumping to the conclusion that something is impossible, one should make sure he understood perfectly the requirements, that he studied in depth all possible scenarios, that he consulted all available resources and tried to find all possible angles from which the problem could be attacked. I'm not saying that everything is possible or that one should hide if a problem is insolvable. All I'm saying is that it's really not ok for someone to start a priory by "we can't do that" without making sure it cannot be done under all circumstances.

BTW, requests that cannot be completed no matter what are very rare - usually managers and customers have a sense for what is absurd and what is not and don't ask for impossible things or, at least, are willing to discuss options. Most of the time it cannot be done because of miscommunication and lack of mutual understanding. Even under insane deadlines, something can usually be done, but may require changing the requirements and a close tracking.

How Do YOU Want To Be Treated?

2009-06-19T22:49:00.030+03:00

Disclaimer: any resemblance to actual characters or facts is just a coincidence. This post does not discuss a specific person of event but

rather tries to underline the idea that people need to be treated with respect, regardless of their position.

Let's start by sharing a link: the ethic of reciprocity summarised in a well known phrase, rooted in the culture of many people: "do to others what you would like to be done to you" or, as it is known across the globe, "The Golden Rule".

Some managers may forget it, being blinded by their function, so they start patronising their subordinates. Others, probably driven either by incomprehension of their role - to service the team to do its job - or a sense of insecurity, position themselves too far from their people thus impeding informal communication or, even worse, rely solely on the argument of hierarchy to force the completion of their goals (instead of discussing personally and try to find mutual understanding). Don't worry! If the team doesn't tell you stuff, they will share it among themselves, behind your back :). I personally don't like hearing words like "subordinate", supervisor" or "hierarchy" when it comes to me and my men. It's not that I am an anarchist of some kind - far from me that thought - but in many ways I find them to be a relic of the past, of times when people were considered brute work force, with no rights and no dignity. Basic needs include food, water, a shelter and security but, right after that comes dignity. Every person needs to be treated with respect and be given a private space to react and sustain his ideas even during an argument. This is actually the reason why negative feedback should be kept private. I find it outrageous when a manager calls his team "a bunch of thick skins" or other names, either in private or in public. He should, under all circumstances, refrain from such judgements.

How I want to be treated by my supervisor is how I expect that I, in turn, treat my team and my team treats me in return - as partners. Me with my responsibilities, him / they with his / theirs. We are all here to build great products for our customers so we are sailing in the same boat, as they say. We should understand and respect each other's responsibilities and act accordingly. I don't mind being guided and shown what and why we go in a certain way but I do mind being patronised. I do mind if I am treated as an inferior being instead of being respected for who I am, for what I stand for and for what I do. I do mind if I'm being dismissed without first being listened or not be given a chance to speak my mind. I do mind also if my values are treated with disregard. Never forget that almost every human on Earth wants to be appreciated for his right judgement and I am no different - and chances are that neither are you! Even more, I consider myself a trained specialist, with something valuable to say. I want to be able to express my personality and have the space to manifest my ideas and thoughts especially because I believe that my greatest asset is my mind - that's why they hired me in the first place, right? Who am I? I'm not only Alexandru; these needs are not only mine, they are universal. So, don't forget: PARTNERS: your boss, your colleagues, your team!

Comment:

Some people may argue that not all men/women are the same in what they want and not every one expects to be treated the same way or have the same values as another one has. Totally true and this is precisely why I feel that my argument is solid. One of the first duties of a manager is to adapt his communication style to each of his team members as he, in turn, expects the same thing from his manager too - adaptability, respect, cherish diversity of thought.

Creativity and Innovation

2009-06-14T09:12:00.010+03:00

This post is a collection of ideas gathered from others, ideas that seem so natural and obvious but many people fail to apply them when it comes to innovation and creativity.

IDEO: build on ideas of others
IDEO: stay focused on the problem
IDEO: you don't have to tell people what to do. give them a great problem and they will do the job themselves
IDEO: one conversation at a time
IDEO: don't criticize
IDEO: encourage wild ideas. You don't get to see the value of an idea first of. You have to live with it for a little bit
IDEO: listening to your current customers can sometime stop you from being innovative. People are used to tell you what they already have plus a little bit more
IDEO: start with the user experience and then build the technology to support it
Sketching on a piece of paper is like brainstorming with myself
Fail soon to get things done faster
IDEO: give the user feedback
IDEO: encourage diversity. As the product complexity increases you need more than one type of specialist: you need psychologists, designers, computer engineers, brand research, graphic artists and a lot more
IDEO: most great ideas come from small, focused, autonomous teams
PHILLIPS: focus on people, focus on user experience

Obvious, isn't it?

Steve Jobs Quotes

2009-06-06T18:05:00.003+03:00

A lot of companies have chosen to downsize, and maybe that was the right thing for them. We chose a different path. Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets.

Apple's market share is bigger than BMW's or Mercedes's or Porsche's in the automotive market. What's wrong with being BMW or Mercedes?

Steve Jobs: 1955-2011

Be a yardstick of quality. Some people aren't used to an environment where excellence is expected.

Design is not just what it looks like and feels like. Design is how it works.

I think we're having fun. I think our customers really like our products. And we're always trying to do better.

I want to put a ding in the universe.

Innovation distinguishes between a leader and a follower.

It is piracy, not overt online music stores, which is our main competitor.

It took us three years to build the NeXT computer. If we'd given customers what they said they wanted, we'd have built a computer they'd have been happy with a year after we spoke to them - not something they'd want now.

Pretty much, Apple and Dell are the only ones in this industry making money. They make it by being Wal-Mart. We make it by innovation.

Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.

The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.

To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.

Why join the navy if you can be a pirate?

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.

Not Employees But Strategic Partners

2009-06-06T16:51:00.010+03:00

One of the duties of a manager is to create a sense of urgency within the team. This is not without a purpose as delivering sooner means not only cheaper but also hitting a market window opportunity, enhanced creativity due to constraints, sense of completion and a lot more. However, creating such a state is very difficult as many managers (including myself) are not always able to come to their team with a solid answer to "why do we need to rush?" question. Most of the time, we mumble something like our boss told us so and we have to obey him. Quite lame, isn't it? There is, however, a powerful tool and a good reason behind the tight deadlines except costs - that is, the company strategy. Often neglected because managers think their employees are not interested, the long term strategy and the overall company vision give the answer to many questions concerning the project and its constraints. Communicating the strategy in a way that is understood by people will turn them into strategic partners rather than simple employees - a part of something bigger, something that makes sense and has a reason. They will better understand what is expected of them as they will see their place in the bigger picture. They will also grasp what is coming up next and also increase their loyalty because they have something to be loyal to. Every human being wants to catch a small glimpse of his future and if managers are capable unveiling the bigger plan (strategy) it will provide at least a partial answer to this natural human need. People who understand their role are much likely to give you trust and have the tendency to rally toward a common goal even if the future is cloudy. So tell your teams about the company strategy and you should be able to see miraculous results.

Why Become A Manager?

2009-06-06T15:50:00.028+03:00

Many people don't understand or don't have a clear image of what means to be a manager so, I thought, it would be nice to drop in a few lines on the subject as I see it.

Beside the normal plan - organize - monitor - adjust activities and the tons of emails associated with them, for me the most exciting part of being a manager is where I interact with the team; it's the feedback, motivation, conflict management, team building, developing others activities that I really like.

A manager is "somebody who gets results through people", so one of the most important part of the job is... others. Many people would like to be promoted not because they want or have the skills to be managers, but because they see the job as a recognition for their good work when this should not be the case. The language doesn't help much as "promoting" means going up where being promoted to management means taking on a totally different role. It's a new job altogether, that can be a real pain for somebody who doesn't have the inclination or the drive to do it. It's the "best salesman" syndrome. You take the best sales person you have and you promote him / her as the manager of the sales department and, as a result, you loose a great sales person but you get a poor manager.

Unfortunately, the career paths in many companies don't help much as the management paths are well developed whereas the specialist paths may be not.

At first glance, the management career seems to be much richer and filled with opportunities. However, the best places to work are those where diversity is encouraged, where there is job rotation that don't allow people to become bored at work (e.g. after three years as render programmer, an engineer is promoted to... network programming and after that sound and so on). These places encourage horizontal move and cherish expertise. Good managers realize that creating an aura of glory for every job and for anyone that is performing great is the way to go and by doing so they make sure the talent is best used, people are motivated and come to work with pleasure. They encourage diversity, new ideas, teamwork (instead of competition for the manager's chair), innovation and respect among peers.

Some companies don't respect specialists too much. Sometimes great engineers are placed in some obscure corner, on small desks, when even the most junior manager has a bigger desk with natural light. Sometimes, engineers are not listened to and their opinion is not taken into consideration. Fortunately, these companies tend to bleed expertise and they soon become dry out of talent - natural selection, I guess. Even more, as organizations tend to flatten, less bureaucrats are needed and more emphasis will be put on highly qualified, high performing individuals. Not respecting or not paying enough your engineers is a deadly sin these days.

Organizations that cherish talent become more agile as management is moving from "paperwork" to genuine leadership and more managers spend their time making sure their star performers get all they need to perform (google "servant leadership"). Today good managers are those who are able to service their teams, to create a place suited for innovation, motivate individuals to do their best, lead the way by finding new opportunities and let the spotlight fall on their teams instead of their own ego. This, I guess, is the manager of today and tomorrow. What do you think? Is it for you? And don't think about the paycheck as in today's business world money is tied more to talent than to position and if you are not extremely good at what you do, no matter what that is, nobody is going to pay you anything (and the reverse is true also).

To sum up, my opinion is that you should become a manager if you like working with people. Not just being friendly to them, but to actually strive to create a better place for them to grow, become creative and also let them get the glory. Don't become a manager if you like your technical job or if you are the "do it yourself" kind of guy; choose a technical path instead, as technical paths will become more and more valuable as companies strive to innovate in order to survive. Find a company that cherishes creative talent and you should be safe and happy.

Note:

One of the main difficulties that arise when an engineer is promoted to management is that the main reason he or she was promoted is because he or she is seen as a person that "gets stuff done". As a manager, on the other hand, he or she needs to let this habit go and make sure that others "get stuff done", which is very different. Most likely this is why so many managers find it very difficult to properly delegate, thus frustrating their employees.

Other articles that shed some light on leadership / management:

Inspiring Game Development Article

2009-05-08T13:07:00.004+03:00

How to Prototype a Game in Under 7 Days:
Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester

http://www.gamasutra.com/features/20051026/gabler_01.shtml

Quote from the article:
"
Handy Cut-Out List!
Setup: Rapid is a State of Mind

Embrace the Possibility of Failure - it Encourages Creative Risk Taking
Enforce Short Development Cycles (More Time != More Quality)
Constrain Creativity to Make You Want it Even More
Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent
Develop in Parallel for Maximum Splatter

Design: Creativity and the Myth of Brainstorming

Formal Brainstorming Has a 0% Success Rate
Gather Concept Art and Music to Create an Emotional Target
Simulate in Your Head – Pre-Prototype the Prototype

Development: Nobody Knows How You Made it, and Nobody Cares

Build the Toy First
If You Can Get Away With it, Fake it
Cut Your Losses and "Learn When to Shoot Your Baby in the Crib"
Heavy Theming Will Not Salvage Bad Design (or "You Can't Polish a Turd")
But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music
Nobody Cares About Your Great Engineering

General Gameplay: Sensual Lessons in Juicy Fun

Complexity is Not Necessary for Fun
Create a Sense of Ownership to Keep 'em Crawling Back for More
"Experimental" Does Not Mean "Complex"
Build Toward a Well Defined Goal
Make it Juicy!

How To Make a Successful Game?

2009-03-19T12:20:00.014+02:00

There are two conditions for a successful game

basic, implicit requirement: the game hits the shelves
the game is fun enough for enough people to buy it and make it profitable

The fun part is, in term, defined by quality and gameplay:

Few bugs, no showstoppers
Smooth game experience, accessibility, gradual learning curve, no unnecessary frustration
Minimum workload for the player
High quality audio and render, beautiful landscapes, credible animations and behaviors
Interesting setting, meaning, learning value
And many more

There are also many more variables, conditions and restriction like, budgets, sales forecast, tough competition, marketing, distribution, etc... How do we achieve all that? It may seem impossible at first but some people just do it. For a successful game to be produced, a series of skills and roles must be defined and assumed. It's not only a one man's show as it was in the early 80's but rather a team effort, based on creativity, technical skills, organizational skills, artistic vision, communication and, above all, passion for the job and strive for self improvement.

The game core team usually consists of:

a producer (project manager)
an associate producer
an art director (gives the unity in terms of looks and the overall artistic direction of the game)
a creative director (handles the core gameplay mechanics, responsible with the fun element)
a lead game designer (manages the game design team)
a lead game programmer (manages the game programming team)
graphic team leader (manages the graphic team)

These people are responsible for the project, each with his own role and expertise. It's not only them, it's actually the whole team but these guys are generally accountable. They must be, by default, highly motivated and have full faith in project. These guys should explain to the team the means and the purpose of what they do, be convincing and also be a role model for each and every other team member. They are the leaders, they provide the vision and the organizational framework for the project and so, they are not allowed to disrupt the team in any way, they must be coherent in their actions and coordinate among themselves accordingly and must have the talent to ignite passion in the rest. A negative behavior is not tolerated in front of the men. They must understand not only the fun element of a game but also the business requirements and adapt their actions accordingly.

Foot note:

There are two main things that must be taken into account when building a game:

complete it and mitigate risk
strive for new, for fun

These must be kept in balance for the project to succeed. The first part is mandatory and is more traditional: "define tasks, deadlines, complete them in time" the other part comes from the team (core or not) and their passion. If the passion is not there, the game will not be a success even if it is completed in time and has only a few bugs. (actually, if the passion is not there, the game will also not be completed in time because it's just too much work to be done and too many challenges on the way). So passion is the key ingredient in this business.

The Pragmatic Programmer - An Exceptional Book

2009-03-15T00:40:00.006+02:00

A must-read for any programmer and not only. Doesn't cover a specific technology or programming language but rather focuses on the mindset a true, pragmatic, effective programmer should have. Short, easy to understand, full of clear, concise explanations, tips and quotes.

http://www.pragprog.com/the-pragmatic-programmer

Quote - Bugs And The Agile Way

2009-03-07T12:16:00.001+02:00

"1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream."

Full article:

http://agilesoftwaredevelopment.com/blog/jackmilunsky/accounting-bugs-agile-way-2

Leader Role, Manager Position In the Team

2009-03-07T11:50:00.005+02:00

Why I Like My Job and The Gaming Industry

2009-01-31T22:27:00.005+02:00

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

2009-01-31T20:32:00.010+02:00

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 :)

Leader

2009-01-31T20:29:00.004+02:00

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.

A Jack Welch Story

2009-01-08T22:13:00.009+02:00

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)

http://www.standard.ro/articol_45402/jack_welch__romanii_nu_pot_ajunge_in_tinerete_manageri_in_vest.html

http://www.standard.ro/articol_46708/exclusiv_tmc___jack_welch__credem_ca_oamenii_incearca_cu_disperare_sa_reuseasca.html

http://www.standard.ro/articol_46800/jack_welch__catre_top_manageri__de_ce_este_atractiva_romania.html

Knowledge Transfer

2009-01-06T11:12:00.005+02:00

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.

Debate Invitation: Design Documents Versus Mock-Ups*

2009-01-05T22:02:00.028+02:00

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?
------
Note:
* 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

2009-01-05T21:53:00.007+02:00

Here is a blog to follow: http://agilesoftwaredevelopment.com/

Some highlights:

10 Principles of Agile Project Time Management:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/10-principles-agile-project-ti

The 12 Best Questions for Team Members:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/12-best-questions-team-members

Professionalism = Knowledge First, Experience Last:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/professionalism-knowledge-first

Kano Customer Satisfaction Model:
http://www.12manage.com/methods_kano_customer_satisfaction_model.html

SCRUM:

http://agilesoftwaredevelopment.com/scrum/simple-product-backlog

http://agilesoftwaredevelopment.com/scrum/simple-sprint-backlog

Project Constraints

2008-12-16T23:44:00.015+02:00

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

2008-12-14T21:14:00.010+02:00

'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

2008-12-13T13:08:00.024+02:00

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

2008-12-09T23:04:00.014+02:00

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?

2008-12-02T10:49:00.006+02:00

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

2008-12-01T09:27:00.012+02:00

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

2008-11-30T15:01:00.013+02:00

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

2008-11-30T14:04:00.009+02:00

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

2008-11-30T09:07:00.017+02:00

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

2008-11-29T19:47:00.006+02:00

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

2008-11-29T19:24:00.006+02:00

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)