Author Archives: c-braley

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
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley 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
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley 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
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance
Testing

Chapter 7 hit home
for me in ways unrelated to programming as a lot of stuff seems to be
for me lately. It seems no matter the jobs I have done, there seems
to be a lot of similarity between them. I am probably only going to
hit on a few points that struck me in this chapter. The first was his
co-worker wanting him to show him how to script something and Bob
ended up writing the whole thing calling himself the tool while his
co-worker was the sculptor who had soon lost interest or realized
that what he initially wanted to do himself was actually harder than
presumed. I find that this has happened to me in the past and I have
been on both sides, the sculptor and the tool. I t is pretty cool to
me how different areas of expertise seem to have similar issues, just
different ways of solving them is all, a different tool set if you
like.
His take on
premature precision is spot on as well. I like how he put it it,
“Business people want to know exactly what they are going to get
before they authorize a project. Developers want to know exactly what
they are supposed to deliver before they estimate the project. Both
sides want a precision that simply cannot be achieved, and are often
willing to waste a fortune trying to attain it.” That is beautiful
and 100% true. Everything always looks better on paper as he says and
once the final product is out there is usually some well I wasn’t
really expecting this or that or I thought that it was suppose to be
or do this. I do like his take on low precision requirements for
estimates as that is exactly what they are estimates and to include
error bars with them. I think there should be no surprises when
writing up an estimate or planning out work for a customer or boss
and that things should be made as clear as possible. It isn’t 100%
perfect, but what is?
The Definition of
Done is another good one. What exactly is done and how do you define
it? I like his answer, “all code written, all tests pass, QA and
the stakeholders have accepted. Done.”. That is for sure a good
definition of done, but I think that done can be defined in many ways
depending upon the project you are working on. It could be all steps
are done for an iteration or a portion of said iteration possibly and
I believe that each team or work environment should make their own
definition of done with the possibility of even modifying it if need
be.
I think out of all
of the chapters so far this one has given me the most value as I
think that a lot of this I will end up putting to practice in some
way or another. Automating acceptance tests to save time is crucial
and to facilitate communications between both parties and how to
eliminate communication errors. It isn’t always going to work in
all cases but I think there is a lot to learn here for me.

Chapter 8 Testing
Strategies

I am not going to
ramble on about every detail here as I think this has been covered
and will continue to be covered until it is second nature I would
hope anyhow. It seems like TDD is the way these days, at least for
some and I agree that it is extremely, if not the most important part
of the job. I understand that the code has to be written but if it
doesn’t perform like it should then what good is it. I think the
parts about QA should find nothing are great and that if they do it
should be an extreme surprise. That means you did your job. I think
or hope where ever I end up landing a job that they put a good amount
of time and effort into testing. I really don’t have much
experience in testing as the pyramid is laid out, I have only really
done unit testing on a microscale basis, but for sure can see the
benefits as you move up the pyramid. I thought the “Bug Hunt” day
was a pretty cool way of testing the product as it gives everyone
incentive to find bugs and ensure that the software is performing to
standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.