aspose file tools*
The moose likes Agile and Other Processes and the fly likes ship it: building developers Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "ship it: building developers" Watch "ship it: building developers" New topic
Author

ship it: building developers

Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31074
    
232

One of the blurbs in the book description is: "How to build developers as well as product"

Does this refer to developer training, teamwork, process or something else entirely?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Pat Hill
Greenhorn

Joined: Jan 17, 2005
Posts: 3
The other I noticed was: What's normal on a project, and what's not.
I would think it has to be "what's acceptable on a project and what's not". Somethings' might happen so often on so many different projects (who hasn't been to numerous unproductive meetings?) as to be considered "normal", but may not be acceptable.
Jared Richardson
author
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
Originally posted by Jeanne Boyarsky:
One of the blurbs in the book description is: "How to build developers as well as product"

Does this refer to developer training, teamwork, process or something else entirely?


Yes.

Check out the Key Practices poster. Several of the ideas deal with developer training and teamwork. For example, in Techniques, Code Reviews refers to mini code reviews held several times throughout the day. Intead of holding your code for a grand 50 page review, we suggest reviewing the code very frequently. This helps to share the ideas in your head with other developers (training them), lets the reviewer give you feedback (training you). Here's a quote from the book describing the reviews: (sorry for the formatting... I'm experimenting.)


Don�t wait too long for any one person to have the time to do a review;
walk around the shop, and find somebody who�s not deep into a problem.
Walk to the other side of the building if you have to, but find
someone. If it�s someone you haven�t used for a code review before, this
is a great opportunity for them to see what you do.

These quick code reviews promote mentoring without the overhead of
a formal program. By varying the developers you work with for code
reviews, you get the benefit of a variety of developers� experience and
expertise. Each reviewer will point out different ways to solve the same
problem. Some better, some not, but all different.

Tip 18: Always review all code

The goal is to learn how to think creatively while also improving your
product. Learn to look at your own problems from different points of
view. These short code reviews will become second nature over time,
and just like microwave ovens, you�ll wonder how you ever survived
without them. Practical discussions of algorithm analysis or resource
constraints are lessons that are taught (and remembered) because you
have a practical and immediate application.

Rather than academic book learning or certifications, you�ll be sitting at
the workbench of various craftsmen (some masters, some apprentices)
learning a little bit from each one, adding their tricks to your own, until
one day you are one of the master craftsmen yourself.


The goal for the code review is both developer training as well as teamwork.

Another Key Practice is Daily Meetings (similar to the Scrum dailing meetings). The idea is to meet very briefly every day (1 to 2 minutes per person). Each team member answers three questions. What did you do yesterday? What problems did you encounter? What do you plan to do today?

When young team members talk about their problems, the more experienced developers have mentoring opportunities, resulting in training.

Everyone meets and talks ~every day~. This type of daily interaction is a great team building exercise.

As to process, check out the bottom of the Key Practices poster. We devote a large portion of the book to Tracer Bullet Development. Tracer Bullets require team interaction at the beginning of the project and throughout the development cycle.

We believe that building software is an holistic process. If you want to build teams and product, you can't do it in a vacuum. Each area (Techniques, Infrastructure and Process) must all play a part.


Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
Jared Richardson
author
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
Originally posted by Pat Hill:
The other I noticed was: What's normal on a project, and what's not.
I would think it has to be "what's acceptable on a project and what's not". Somethings' might happen so often on so many different projects (who hasn't been to numerous unproductive meetings?) as to be considered "normal", but may not be acceptable.


Great point! Can I blame the publisher?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ship it: building developers