Chapter 2 Notes - Rapid Development

Summary

...he sent Mickey a postcard from Ottumwa, South Dakota--- a picture of himself riding a giant jackalope--- but no one knew when he would be back.

(Note: I am reading from a kindle so no page number was available. All quotes are from chapter 2.)

I did not read the first chapter which is fine because Chapter 2 was an introduction. The main takeaway is this: ``\dots your software project operates along four important dimensions: people, process, product, and technology.'' The author stresses that companies and other books tend to focus on just one of these but for a truly efficient and ``rapid'' development, all 4 are required. He says each are dimensions and should be looked at as a whole. The first thing he emphasizes is People. He discusses people who work for these tech start-ups and large corporations. Everything he is saying is true. I was born in 1997 and this book was written in 1996, and things haven't changed much have they?

``NASA's Software Engineering Laboratory have concluded that technology is not the answer; the most effective practices are those that leverage the human potential of their developers.'' I think this statement is more common sense. Ford realized this in 1914. When an employer gives his developers better pay and better lives, he will get more potential and better output. Workers have issues of motivation, teamwork, staff selection, and training. The five issues of software staffing are: Top talent, Job matching, Career progression, Team balance and Misfit elimination. The most surprising here is misfit elimination. Eliminating problem team members. I think that would be much harder today than it was in 1996. Also, I liked the job matching. Not just putting a team member were you think they are needed but letting them gravitate towards the job they want to do.

``Process represents an area of high leverage in improving your development speed.'' The most important part of the chosen process is Rework avoidance, Quality assurance, Development fundamentals, Resource targeting, Lifecycle planning, and Customer orientation. Rework avoidance stood out to me here. The further a bug goes without being seen the harder it is remove. That is same for features that the customer decides were not needed or wanted. ``A lifecycle model is useful because it describes a basic management plan. For example, if you have a risky project, a risk-oriented lifecycle model will suit you; and if you have vague requirements, an incremental lifecycle model may work best.'' Basically, fit the lifecycle model to your development style.

The bigger the product and the more ambitious the goals, the harder it is to implement the product in a reasonable time. If the product is broken down into smaller pieces, it is easier to plan.

``The change from low-level languages like assembler to high-level languages like C and Pascal was one of the most influential changes in software-development history.'' Using an easy to implement language for development would make an organized, rapid development easier. It woudl also help curtail mistakes. I can also see AI helping.

Attention Grabbers

1. ``The research results simply say that the effects of individual ability, individual motivation, team ability, and team motivation dwarf other productivity factors. They do not say specifically that team T-shirts, free soda pop, windowed offices, productivity bonuses, or Friday afternoon beer busts improve motivation, but the implication is clear: any organization that wants to improve its productivity should be actively trying all these things.'' Didn't Microsof try this? And Google?
2. I appreciated the story at the beginning versus the one at the end.
3. ``Since the late 1960s, study after study has found that the productivity of individual programmers with similar levels of experience does indeed vary by a factor of at least 10 to 1.'' I think this is still true today. Your top performers will out perform your average performer. I want to think that I am between average and top. I am not a top performer but I am also not the laziest either.
4. I don't remember where it is but he also talked about adding another team member to make the work go faster but instead you just add more communication issues. It raises the budget 33 percent. Sometimes more is not better.
5. If you are a well paid software developer, you can show up to the office in shorts and also take four months off to take a bike ride and see a jackalope.

Questions

1. With the steady loss of entry-level software jobs to AI and the requirements taht keep increasing, is people as a dimension diminishing?
2. In order to balance all four dimensions, is there an order you are supposed to do them in, or does it just depend on the project?
3. How do you actually get rid of a problem team member without wrecking the team's morale or getting into HR trouble in this day and age? Some team members are good riddance but some are part of the team even if they aren't good at their job.
4. I do like the concept of job matching, what happens when everybody drifts away from the boring stuff nobody wants to do?
5. I find it interesting that programmers with the same experience can vary by 10 to 1. Is that because of natural ability, their environment, motivation, or just how you measure the work?

Leftovers (Optional)

This book is somewhat entertaining to read. I was surprised because I always think textbooks are going to be a slog.