Monday, October 29, 2012

About Corporate Wallpapers

Recently at work, they imposed a new domain-policy to force a corporate wallpaper (background) for everyone's workstation (desktop). I haven't noticed  it until my password expired and I ended up doing a reboot, when all new policies were applied by the log-on script. After this, my wallpaper was changed to a corporate image (the most recent advertising campaign); of course I was immediately upset.

After calming down myself, I began to wonder why they do this? Later I discovered that some days before the company sent an official email memo explaining the whole thing. They said that the wallpaper will be changed automatically whenever a new advertising campaign gets released.


Not totally bad

I must admit that this kind of policy is understandable when you have your staff visiting clients and vice versa. 

If you'll be in direct contact with clients your workstation (Desktop or Laptop), becomes a reflect of the corporate image (as well as your dress and physical aspect). 


But...

But why you should apply that kind of policies to all your staff?

For me, and almost the 90% of my co-workers, this is a nonsense because we never get in touch with our clients (the end users of the applications we work on). We have some internal clients (administrative staff), but they are just another employee; the difference is that they belong to the business people. Even more, we usually show our work in a test server and all applications are web-based. So nobody is looking at my desktop background in the 99.99% of the time. Then, Why to force a corporate wallpaper?

My only guess is that employees are so poorly identified with the company values and campaigns; that they must force us to look every piece of advertising to change our mind. In contrast, I've seen some  employees, from other organizations, changing not only their desktop background with the  company's latest promotion, but also their phone's screens have the same the same background.


Instead of

Instead of that sort of manipulation, I think that companies must always pursuit a sincere motivation on their collaborators. That way they'll become brand-evangelists in a volunteer manner; and there is no better salesman that the one who, truly, believes on the product.


Samples

I did some Google-based research, and found one example of each point of view: the ones who are in favor of "Corporate Wallpaper"-like policies and the ones who don't. You can tell, by their title, which is which:
There seams to be a strong interest for system administrators to enforce Corporate Wallpapers. Take a look at this stats from search results:
  • "How to force a corporate wallpaper": About 75,000,000 results (0.34 seconds)
  • "corporate wallpaper policy": About 11,000,000 results (0.33 seconds)

From the top 10 results of the first search I want to highlight a "winner":
"One of the things that is unique to us is the fact that we change our desktop wallpaper across all computers as needed.  Unfortunately, ... users change their own wallpaper to something else ...  Once the users change this to something else, we were unable to force the windows wallpapers to change on the computers. 
Not until I did a bit more digging and research.  Now, ..., we force it to do so based upon a login script." (from How to Force Windows Wallpapers to Change)
People responsible for applying that kind of policies seem to be very proud of it; but no one is looking at the psychological effects of those decisions.

Phrase of the Software Craftsman 006


"Code should be composed in such a form as to make it readable by humans."

Sunday, October 28, 2012

Tips when changing job

For most people, changing a job is a matter of money or power. You move if the new company offers you an attractive compensation package. Or, you move if you are just a worker and there you will be managing / leading others. Also you have others that look for the state of the art tools and methods; they will move to a new job if they find that there are using the new stuff. In summary we have three buckets; one big for the ones looking for money, another for the ones looking for power, and the last one for those state of the art addicts.

As you mature on your career, and life, you start to value some others aspects. Suddenly the money pass to a second place. Also, if you are good on what you do, there is no need to be a manager or leader in order to increase your incomes. You start looking at your company management philosophy, things contributed by your team (to you) and vice versa, turnover ratio, physical aspects of your work-space among others. All those variables lead to the fundamental question: Is this a good place, for me, to work?


What is a good place to work?

  • How flat is their structure? Typical employee to manager ratio, for our industry  is between 8:1 and 10:1 (one manager every 8 to 10 workers). But when I talk about a flat structure, I'm not looking at the first level managers ratio. Is about how tall is the chain from them and up. The more levels in the management chain, the more bureaucracy you'll have. Also the company ability to conform organic teams is very important. Imagine that you start working in a new project involving 3 or 4 groups (and of course their leaders); this can put you in a cross fire coming from each manager try to control or imposes his ideas. A really organic team, must not suffer for those political issues; and if so that is an indication of how immature are those managers.
  • Team's social interactions: A very simple, but accurate, gauge of the company's people-oriented traits is the social interactions among team members. The more informal interactions (celebrations, meetings, chats, parties, events, etc.) you notice in a team, the more good is that company in keeping people happy. Of course, you could find a very united team inside a non people-oriented company, but those are the exception. Usually when people are unhappy, they tend to use their free time to be as far as possible from the job (and coworkers).
  • Turnover ratio (1): High turnover rates creates an inexperienced work-force, this leads to more mistakes and low quality products. Also a constant and high turnover creates the perception that the company is always about to sink; and nobody wants to wait until the last moment over the Titanic, right. More about the importance of measuring the employee turnover here.
  • Career path: Low turnover is associated (not only), to a career path policy. If the company has a well established training program, employees don't try to go away so often. Also a career path program indicates that the company is concerned about your growth. Its main focus is not on taking advantage of your knowledge, and later replacing you as a depleted resource (BTW, Do you like the term "Human Resource(s)"? I like better "People" or "Staff"). 
  • Size matters: How big will be your monitor? (Couldn't say it better than here). How fast will be your new workstation? How many GB will you have? You have to pay very close attention to the resources the company allocates on workstations, for their workers to feel comfortable. These details are an indicator of how much the company cares about the people. If they prefer to save a few bucks and put people to work on low-performance PCs, and small monitors, that company don't deserve your collaboration.
  • Other environmental issues: 
    • Respect for the Intimacy Gradient (2) (pattern #127, from A Pattern Language: Towns, Buildings, Construction. [Oxford University Press, 1977]). You need to have place(s) to work alone, in small groups, in big groups and also public (social) areas. All these different intimacy levels, must be located in a way that no group or persons interrupt others. One key indicator that a company does not respect the Intimacy Gradient, is the factory-like disposition where all desks are places in a grid with just little, or none, division. With such a disposition you can not work alone (because of the surrounding noise). Group work just causes more noise. This point, naturally, connects with the next one ... 
    • Noise level: what is the average noise level on your future work-area? This is a very subjective aspect, but is well know that we, brain workers, can't do a decent work without the proper concentration. Noises affect directly your capacity to concentrate. 

Summary

Next time that you start looking for a new place to work, take all the previous variables into consideration. Ask for a visit to their installations. Find, at least, one person inside that you know; and another that you don't know; have an informal chat with them about the company. Later compare their versions.

Ask your future manager / leader what are the training policies of his organization (if any). Ask if he has the turnover rates for the last 6 month. Try to gather as much information as you can about your future team social interactions. Finally, with all that information in place, take your decision.

Please note: With all this, I'm not saying that money, new tools and technology are not important. They are, as well. But we tend to forget about the mentioned topics, and just focus on our new salary and that  new toy we will be playing with.



(1) Turn Over Ratio: A simplified formula to calculate the turnover rate is: for any time period get (I) Avg employees and (II) How many people left the company; then divide II by I and multiply by 100.

(2) Pattern #127 - Intimacy Gradient:
Conflict: Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients, family, will always be a little awkward.
Resolution: Lay out the spaces of a building so that they create a sequence which begins with the entrance and the most public parts of the building, then leads into the slightly more private areas, and finally to the most private domains.

Wednesday, October 24, 2012

Coding Dojo @DR 003

Below you'll find all details of the Coding Dojo @DR 003 meeting. Please comment on this post with your opinion or concern on any topic. 

This time we'll be practicing with a Kake format (see Little Coding Dojo Intro for a details on each format). We have an open discussion on Google Moderator (http://goo.gl/wKgwu) to select the Kata to be used. Please go to that URL and vote up for your favorite problem(s). We need at least one PC (laptop) on each team, so bring yours; it might be needed.

Newbies, please check the following references before the next meeting:

I  -Event URL:  http://goo.gl/dkNdT

II -Katas Pool
Go to Google Moderator series http://goo.gl/wKgwu, select your favorite problem(s) or add new ones. We'll pick the one(s) with more votes.

III-Expected attendees: 15 to 20

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda
  1. Inform next session date: 1 minutes
  2. Share moderator link to decide on a Topic for next session:  1 minute
  3. Form groups (3 to 5 members each): 8 minutes
  4. Kake Work (Code!): 120 minutes
  5. Each group shows their solution: 16 - 32 minutes (up to 8 minutes each)
  6. Retrospective. What went well? What was interesting? What was frustrating?: 15 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/BRDR4

VII -Next event date: Tue, Nov 13, 6:30 PM - 9:30 PM

VIII-Actual attendees: 12

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
SQL string generator

XI  -Retrospective 

What was frustrating?

  • This time nothing but the poor level of detail of the selected Kata for some of the attendees. 
What went well?
  • Everyone feels this format (Kake) was more fun than others.
  • All groups work, with different levels of detail, the problem and achieve a solution with its set of tests.
What was interesting?
  • We "taste" a little of new languages.
  • We saw different approaches of solving the problems maid possible by using different tools.
Next meeting agreements:
  • We will be rotating the 3 formats (Prepared - Randori - Kake).
  • The next format is Prepared
  • 3 of us must prepared a Kata (one each). Actually we have 4 candidates +Daniel Paniagua, +Eduardo Burgos, +Rafael George, and +I
  • Each prepared Kata will last from 30 to 45 minutes.

XII -Action Points
  • Confirm availability of the presenters.
  • Confirm Kata's themes and duration.

Monday, October 15, 2012

Phrase of the Software Craftsman 004


"Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking."

Wednesday, October 10, 2012

Coding Dojo @DR 002

Below you'll find all details of the Coding Dojo @DR 002 meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

For this second meeting, I want to emphasize points 3 and 4  of the Agenda. First we need to give a solid an clear introduction to the Coding Dojo Topic (meeting formats, objectives, and rules). Also is  almost mandatory for everyone to understand the TDD cycle and to see, in practice, a solution build using TDD. On the last meeting we noticed that people were unaware of the meeting format and objectives, although several references were given. So, if this is your first meeting; or you have not read the following references, please do it before the next meeting:


I  -Event URL:  http://goo.gl/ykQWe

II -Katas Pool
We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

III-Expected attendees: 15

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda
  1. Decide on date for next session: 5 minutes
  2. Decide on a Topic for next session: Just TDD (0 minutes)
  3. Coding Dojo and TDD introduction: 15 minutes
  4. Code! PreparedKata by Lorenzo Solano (Roman Numerals): 30 minutes
  5. Pick a / some Kata(s) for this session: 10 minutes
  6. Code! RandoriKata: 45 minutes
  7. Mid-session break to discuss how things are going: 10 minutes
  8. Code some more: 45 minutes
  9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/2iOTD

VII -Next event date: Tue Oct 30

VIII-Actual attendees: 11

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
Roman Numerals (prepared), and Word-wrapping (randori).

XI  -Retrospective 

What was frustrating?

  • Low focus on the problem at hand, participants were talking during the hole meeting about other topics.
  • Too much noise.
  • Some of the attendees were not on time.
  • Some people think that we need more "real" problems. By real they mean problems more like the ones we faced every day at work. Also they mention less-algorithmic problems.
  • Definitely, we need and external keyboard and mouse.
  • Allocate enough time for each problem, so we don't have stop and unfinished solution. 
  • Plan to have a meal.
What went well?
  • In general this meeting was, by far, more organized than the previous one.
  • We cover all points in the agenda.
What was interesting?
  • Was interesting to new ones.
  • We have knowledge sharing.
Next meeting agreements:

  • We'll have a Kake format.

XII -Action Points

  • In the future, we won't put more than one meeting format for a dojo session, to ensure that we have the time needed to work on problems.
  • For the next meeting, we need to define an "expert" on each programming language to be used on the Kake meeting. 

Monday, October 8, 2012

Phrase of the Software Craftsman 003

"[...] spending time keeping your code clean is not just cost effective; it's a matter of professional survival." 

Wednesday, October 3, 2012

Agile Atlas


Agile Atlas (see the About Page)

If you are new to Agile, and related methodologies like Scrum, here is an online "Atlas" or Dictionary about all those topics. Below is an extract from the About section explaining, in summary, the site's purpose.
The long-range purpose of this site is to provide an “encyclopedia” of information about Agile and related methods. Although the site is presently supported only by the Scrum Alliance, it is not intended to be a Scrum-only site in any way.

You'll also find valuable articles (@ http://agileatlas.org/articles) related to Agile and Scrum, like this one:
Scrum - a Bird’s-Eye View: A quick overview of Scrum - Agile Project Management

Enjoy It! 

Monday, October 1, 2012

Coding Dojo @DR 001

Below you'll find all details of the first Coding Dojo @DR meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

I  -Event URL:  Kodisto Dojo @Google+

II -Katas Pool
We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

III-Expected attendees: 21

IV -Expected duration: 3:25 hrs. (3 hours and 25 minutes)

V  -Agenda
  1. Decide on date for next session: 5 minutes
  2. Decide on a Topic for next session: Just TDD (0 minutes)
  3. Coding Dojo and TDD introduction: 20 minutes
  4. Code! PreparedKata by Rafael George (String Calculator): 30 minutes
  5. Pick a / some Kata(s) for this session: 10 minutes
  6. Code! RandoriKata: 40 minutes
  7. Mid-session break to discuss how things are going: 10 minutes
  8. Code some more: 70 minutes
  9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/vQ5Xk

VII -Next event date: Thu Oct 18 2012

VIII-Actual attendees: 11 (from 22 confirmed; No-Show 11)

IX  -Actual duration: 4:00

X   -Worked Katas:
Just String Calculator, see retrospective to know why.

XI  -Retrospective (If I forgot something, please comment to let the point registered)

What was frustrating?

  • Use a moderator: Discussions took to long, and some of then were pointless. Also we try to talk all at the same time.  
  • Respect the Prepared Kata format: We should be listening and looking at the techniques (TDD) presented with the prepared and respect the point of view of the person doing it. If someone does not understand a given step, the expositor must explain it; but that does not imply that both, the expositor and the attendee, must agree on the actual decision. The requirement is "not to move forward if someone does not understand the last step".
  • Respect the Agenda: no one respected the agenda, we end-up by working just on one point of it.
  • Respect the meeting schedule: only 4 (of 11 participants) arrived at the expected time.

What went well?

  • Everyone stick to the usage of the technique (TDD) moving the focus away from resolving the actual programming challenge. 
  • We cover all Test Scenarios of the problem.
  • We add more Test Scenarios to the solution.

What was interesting?

  • When is OK to stop the Refactoring step (of Red-Green-Refactor / RGR cycle)? or Is OK to do Early Refactoring?
  • It's OK to put a little of "sugar" on the syntax of the produced code (by using more readable names or by encapsulating standard's API calls with private methods), in order to increase the legibility of the code?
    • Those in favor defend the legibility to decrease the maintenance cost, and to increase the  code understanding.
    • Those against say that the average developer must understand the code. And also that if we add too many methods we'll end-up with a large call-stack, making it harder when debugging.
  • It's OK, or not, to do early optimizations?
  • When to add more test scenarios? 
    • Most attendees agreed that we must complete the original requirements first, and then add more scenarios to shield our code. 

Next meeting agreements:
  1. Next meeting subject: TDD
  2. Next meeting language: Java
  3. Next meeting format: Randori
  4. Place: <TBD>. Go to the Google's Event for more details.
  5. Other programming languages options: C#, Ruby, and Python. Withing the attendees were at least one person with enough experience using each language.

XII -Action Points
  1. Modify the next agenda to include an introduction to the Technique to be used (TDD, BDD, etc...)
  2. Modify the next agenda to include an explanation of the type of meeting we'll have.
  3. Include an early step to read the agenda to participants so everyone is on the same page and  respect it.
  4. Upload the code of the Kata to a public location (github, bitbucket or similar), so everyone can review it.
  5. Test the video recording software before starting with the Kata to ensure it's working as expected.

Phrase of the Software Craftsman 002

"Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug."
-Martin Fowler (Refactoring)

Subscribe to our mailing list

* indicates required
Email Format