Everything and the Mobile Software Universe…

  • rss
  • Home
  • About

Designing the Windows Vista Shut down menu…Do yourself a favor and read!

Thomas Menguy | November 27, 2006

Here is a “Joel on Software” analysis of the MS Vista menu .. and its, hum how to not say something rude, surprising number of available user choices :-) .

The real fun comes just after, when Moishe Lettvin, that was in charge of the developpement of this feature
gives its explanations!…Lenifiant, and “ubuesque”,

…24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let’s add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team — after a year — there was still no decision about exactly how this feature would work.

moblog: The Windows Shutdown crapfest

Really really something to go through…cause it seems that all kind of organizations may tend to those limits. And it is a good list of what NOT to do, or try to not do when your business is growing bigger….

But things can be different, look a little at Google:

From a high level, Google’s process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:

- there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it’s not their main project.

- there aren’t very many meetings. I’d say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead. – it’s quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

- there aren’t Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I’ve ever seen.

- even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don’t work insane hours unless they want to.

These are generalizations, sure. Old-timers will no doubt have a slightly different view, just as my view of Amazon is slightly biased by having been there in 1998 when it was a pretty crazy place. But I think most Googlers would agree that my generalizations here are pretty accurate.

How could this ever work?

Stevey’s Blog Rants: Good Agile, Bad Agile

And read the whole article also cause it is a refreshing rant about Agile … and a good insight at Google success…and why everyone wants to work there!

Comments
No Comments »
Categories
Information Management, Mobile Industry, Software, development process, project management, team management, team work
Tags
development process, Information Management, Mobile Industry, project management, Software, team management, team work
Comments rss Comments rss
Trackback Trackback

Manage or be Managed….so many questions

Thomas Menguy | February 23, 2006

Micromanagement dangers is again a fairly good read from Kathy Sierra, complemented by this great post about motivation by reputation. Those posts led me to think about management practice, what I liked when I’m managed … and what I do when I manage myself.

Communication

  • How do you feel when you miss information, how should you react? / What Info a manager have to pass on to the team? where is the thresold to retain info to not add pressure to your team versus frustration to not being aware of the big picture?
  • Reputation/Image given by little words : other’s work is only known by collegues/management team through his manager words: be really carefull with that: longer term carrier issues may depend on the image of an employee …image given by his manager.

Initiatives, creativity vs workforce/efficiency?

  • How to leverage your team creativity potential while not loosing efficiency? This one is a hard one I think, strongly correlated with the first one: a manager should be able to lower enough the corporate pressure to let its team a certain freedom of movement…hum not a simple task.

Responsabilities and ownership

  • This one is a key part: when a resposibility is given, it must be the full scope: good and bad, reward and pain.

Motivation: corolary to the previous points.

  • Never uderstimate the power of fun … In that regard creating blogs to present what ones are really proud of, in an informal way can be a really good tool.
  • Saying when things are done and well done… with a little “thank you” and “good job”, it’s free and efficient, and corporate culture tends to only raise the “bad done things” … not a good culture to say the least.
Comments
No Comments »
Categories
Software, development process, team management, team work
Tags
development process, Software, team management, team work
Comments rss Comments rss
Trackback Trackback

How to interview a programmer?

Thomas Menguy | October 30, 2005

I’ve came up with this question recently : I need a new team member, but How to choose him/her? What are the good criterions? The right interview questions?.
With my point of view in mind, I’ve made a first interview and, after the interview, found this post at lifeHack.org which emphasizes on reading code from the candidat (I can’t disagree more), but point to a nice entry from artima (?).

For me an interview has to be fair: When I was myself a candidat I enjoyed my interviews (ok, difficult to really enjoy this bright stress moment for a junior) when I had the feeling that I shown what I was ABLE TO DO, that I understood QUICKLY what the interviewers explained, that I had no issue COMMUNICATING with them … But it was no all the time like that, and many interviewers were only looking at my diploma (a good one in France) or my communication skills, really never going down to the code, algorithm, scientific/technical culture etc: even if this last interview category led to some job proposal, I had a mixed feeling about the company: Why did they choose me? They don’t know If I’m goog or bad, Are they all like that? …and so what are the core values in that company? certainly not technical, so “political”?

So I’ve took some times before the interviews, and here are my own tricks to have the feeling to not loose my time and the candidat one’s ;-) :

  • What profile do I really need? … a good question isn’t it? In my case I need a programmer…
    • …but it’s not enough, here a some more precise profiles:
      1. An Executant: someone able to execute well defined tasks, great organizational and coding skills… the “process” kind of guy, able to finish cleanly a product.
      2. A Communicant: this one is able, and like, to be in front of client, write docs and presentation.
      3. A Creative: someone able to bring new ideas to the table, able to impose those ideas, invent new things (certainly not an executant…), this one will defines what he has to do.
      4. The guy who fiddles around: give him something, it will work … but forget about testing and process…
      5. Background : this one is not a profile, but is a measure of the scientific and technical culture of the candidat.
    • Knowing those profiles I try to give a % to each profile for the best match I’m looking for (ex : Executant: 70% Communicant: 5% Creative: 5% Fiddle: 20% for a good release manager ;-) ). Giving that it’s now possible through questions to “extract” this profile … and see if it is matching.
  • Execution Skills
    • Asks for process vision: versionning tools, branching process.
    • Testing: Testsuites? is it something normal for him? who has to test a code.
    • Release view and policies: When could he say that his code is ready to be externalized, what citerions did he choose?
    • C/C++ Code questions (we have a pretty good question list here in Open-Plug :-) ): Synthaxe questions, memory management, etc…
  • Creation Skills: Find some good exercises (I have some good one .. thanks Cadence!), be sure the candidat doesn’t know the exercise before, and listen carefully to the ideas, good and bad he is trying to complete (or not) the exercise.
  • Communication Skills:
    • Let him explain a big and complexe project he has been involved in, if you don’t understand … the candidat has perhaps a communication issue .. or worse few synthetic skills.
    • Talk a little of his passion, hobbies, etc.
    • Try to put him in “bad and stressfull” situation (the exercise given to check its creative skills can be enough ;-) )
  • Fiddle Skills: See if he had done some “personal” technical project, from the ground and how he made it working. How autonomous he can be?
  • Technical Culture: Let him talk about its skills … and ask anything that are (or not) related to your own expertise field, just to see if he is curious and a self-teaching kind of guy.

For me the idea to see some of the candidat own code can be a “false good idea”: Now that I’ve worked with a lot of different coders, on different projects, I can safely affirm that no one code as any other one, and that at first sight I’ve never liked ANY code not written by me, and many times for bad reasons. The only important thing are architecture, algorithm and professionalism (CPU and memory care, readability, testing coverage), but to judge a snipet of code in few minutes we tend to only focus on synthax, programming style and tricks and so only on the style, not the content…bad idea to say the least.

Thomas

Update: Sergiu gave me some nice references for technical questions (mostly C++) :

  • http://www.beyondcode.org/articles/interview.html
  • http://www.techinterviews.com/?p=238#more-238
  • http://www.geekinterview.com/Interview-Questions/Languages/C-Plus-Plus/
  • http://www.duke.edu/web/ACM/interview.html
  • http://www.possibility.com/epowiki/Wiki.jsp?page=CppInterviewQuestions
  • http://oneparticularharbor.net/sam/interview.html
Comments
No Comments »
Categories
Software, development process, project management, team management, team work
Tags
development process, project management, Software, team management, team work
Comments rss Comments rss
Trackback Trackback

What I’ve enjoyed reading

Recent Posts

  • You will be disappointed by your Android Market application sales…think twice before jumping on the little robot
  • Why Adobe should change its mobile strategy (again)
  • No Qt for S40, Maemo and Symbian apps won’t be compatible: is Nokia really willing to unify development for OVI Appstore?
  • Why Samsung Bada makes sense vs an Android-me-too journey
  • Flex on Mobile: What’s coming in ELIPS Studio…iPhone insights (and android teasing :) )

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox