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

The real life of a project (or a project in real life)…GREAT!

Thomas Menguy | October 31, 2006

cimg1528.JPG

Thanks a lot Mag ;-) this is now my bible, and it should be on every project manager desk!

Comments
No Comments »
Categories
Uncategorized, development process, project management
Tags
development process, project management, Uncategorized
Comments rss Comments rss
Trackback Trackback

Agile and Gantt chart : Agile Chronicles: Can Gantt Charts be Agile?

Thomas Menguy | September 28, 2006

Interesting read :
Agile Chronicles: Can Gantt Charts be Agile?

We try to put in place Agile methods here, but even if as software developpers we strongly believe in the iteration process and so one : we have traditional clients that need to know Date/Schedule/What is in a release/Is the project going late? by how?. And for me, and for now, even if Task/user story are “agile” in our process, I need a Gantt Chart to give DATES/DEADLINES/SCHEDULE to my hierarchy, taking into account my team holidays, the impact of bug fixes vs features coming from different clients.
I’m incomfortable in respect to Agile methods because of this deadline thing:

  • Either client/management has to adapt and forget the deadline stuff, accepting many incremental changes and releases….hum forget the incremental release stuff in the embedded space, with those awfull build systems.
  • Agile has to be adapted to present a Schedule and Deadline frontend … because it is what PEOPLE understand, forget team velocity, % completion, etc, the only things clients/hierarchy want to know is by how much days you will be late :-)

What do you think? what solutions did you put in place to make Agile compatible with businesscases?

Comments
5 Comments »
Categories
Software, Uncategorized, development process, project management, team work
Tags
agile_methods, bug_fixes, development process, gantt_chart, gantt_charts, incremental, iteration, project management, Software, software_developpers, team work, team_velocity
Comments rss Comments rss
Trackback Trackback

Software Effort Estimation …

Thomas Menguy | January 11, 2006

Here is an old article I’ve written when I was a student about software metrics/efforts… As I need for my day to day job to have rough estimates of software projects at an early stage, I’ve begun to train myself on it and resurected this old essay.

Read the rest of this entry »

Comments
No Comments »
Categories
development process, project management
Tags
development process, project management
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