Monthly Archives: February 2017

The Clean Coder: Chapters 9 & 10

The Management. Such an interesting topic for a book dedicated to becoming a professional. What Uncle Bob is talking about here is two distinct forms of management; personal management and business management. Interestingly enough, these two topics become intertwined quite often. The first instance in which this appears in the book is when he talks about meetings. When the section starts on meetings Uncle Bob stated something I’ve been saying for years now.

There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.

My current position requires me to attend an occasional meeting, typically conference call style. The one thing I have found is that these meetings are very important to keep people up to date on whatever the contents of the meeting are and it helps get every one on the same page. However, every meeting I have been apart of was by no means short. I believe the shortest meeting I was ever apart of still lasted 45 minutes and by the end I walked out with no more knowledge then I had gone in with. Having had these experiences, when I saw Uncle Bob’s statement about the two truths of meetings I felt relieved that I wasn’t the only one that felt this way. Uncle Bob went on to talk about the different meetings that are had in a Scrum methodology of software development. Reading his thoughts on how these scrum meetings should go is very interesting. Currently with the Capstone class at WSU we are using Scrum and I can see how some of these meetings could go very long. I believe my team and I have done a good job and avoiding wasted time during these meetings, though.

The rest of chapter 9 covers ways to stay focused. Fortunately for me, most of these methodologies or theories appear to be common sense to me and I didn’t take away that much new information from these paragraphs.

Chapter 10 talks about estimates. Interestingly enough, I’ve had to create a few estimates in my line of work. Granted these were extremely small scale and usually completed in under an hour. The thing I learned from creating those estimates was, it’s incredibly hard to estimate time for when things go wrong.

As I mentioned in a previous blog post I listened to a podcast (You can find it here ) on software estimation a few months back. This chapter from Uncle Bob felt like a refresher on the things talked about in the podcast. What I find most fascinating about this subject, is that in my field an estimate is occasionally taken as “set-in-stone” and “done-deal” type of artifacts. However, that’s what business has turned it into and that was never what estimates were intended to be used for.

I don’t have too much more to say about estimates for software, seeing as I haven’t had to ever create one yet. However, I know when my time comes to finally use this information, I will be referring back to Uncle Bob!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapter 9-10

Chapter 9 and 10 of Clean Coder talks about time management and estimation. Both of these issues goes hand in hand. Meetings are abundant in workplaces and it can lead to huge amount of time wasted that could be better used to focus on the project. Of course you need meetings to keep track of progress, give updates of project status, and check if the project is on track with expectation. The key is to find a balance between those two.

Time estimation is something every project faces. The book gives good advice on one should make probabilistic estimate unless they are absolutely sure they can give a hard number of the time it takes to finish a task. In the real world this goes way less smoothly. Many projects even if you are confident in your own ability relies on many other people from different teams, department, and even other companies. You can give an estimate that is only as good as if other people also make their estimate. That is an important key to keep in mind. Sometimes, even when making probabilistic estimation, upper management may want certain goals to reach by a certain deadline. This lead to anything from crunch time to unexpected delay in other task. Practical estimate is good advice, but sometimes it just does not match the practical reality.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 9 and 10

Chapter 9: Time Management

This is a very interesting chapter as everything revolves around
time and it is something that we never seem to have enough of am I right? Of
course I am. I myself have been trying for years to come up with some sort of
consistence as far as a schedule goes, but with my situation up until I started
with college was different as I am on disability so I tried to keep to a
regular schedule so I didn’t get caught in some weird time continuum while I
figured out my next step. I have found it difficult to manage time while in
school though and try to set a schedule, but each semester that changes and
well I get out of sync. Thank goodness this is the final semester (well until
grad school if I go that route) and I will hopefully be gainfully employed
shortly thereafter. Anyways I suppose I should get back to the chapter at hand,
time management. I found it amusing how he referred to meetings as necessary
and huge time wasters because it is so true no matter what your job is. I never
gave much thought about how much per person it actually costs for a meeting.
There are a lot of good points in the chapter concerning meetings in general,
but a lot of it is in my opinion common sense. Have and agenda and a goal. Well
of course there is an agenda and a goal, I know there are a lot of times where
meetings don’t seem to have either but there generally is. I really like the
stand up meeting like we are suppose to do for Agile development. Twenty
seconds per question, no more than a minute per person; in, out, done the way
it should be in my opinion. Short, sweet, and to the point I say. No beating
around the bush. I liked his quote from Kent Beck, “Any argument that can’t be
settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom.
There are a decent amount of items in this chapter I really enjoyed, especially
how he compared stuff to D & D type games, like focus manna, if you use up
all your focus manna in the meeting, you’ll have none left for coding, how very
true indeed.

Time Boxing and Tomatoes. I am definitely going to give this a
shot. I think it is a really great idea to set a timer and let nothing
interfere with your plan, actually carrying out to a tee may be a different story
but still worth a shot none the less. I love it; dividing your time between
tomato and non tomato time. I am actually laughing right now thinking about it,
how many tomato’s did you get done today Jim?
Only 15, slacker! Over all I thought this chapter was well done and a
very important, if not one of the most important things that needs to be worked
out. If you can’t learn how to manage time effectively and overcome adversity
when something hinders your plans, you will have a hard time getting things done
and you will probably find yourself moving out of a job versus up in the job.

Chapter 10 Estimation:

I really like how he put it right out there in the first sentence.
“Estimation
is one of the simplest, yet most frightening activities that software professionals
face. So much business value depends on it. So much of our reputations ride on
it. So much of our angst and failure are caused by it. It is