Monthly Archives: February 2017

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.

The Clean Coder 7 & 8 Week 4

Acceptance testing is discussed in the first part of the reading. This is a broad subject that can be looked at different ways. Some ways this testing can be done is by having someone help you write that tests that doesn’t know how to code the tests. Also when estimating when tests will be complete, it is very hard and should not be given an exact date, but a large time frame. When a test is acceptable it means it is done, fully and completely done.

Different testing strategies are then looked at. The QA team should not find any bugs, but they usually will and are a large part of the testing process. Unit tests are the most broad and cover the most about of code, these tests are mainly for the programmers. Integration tests take component tests and make one big test from them. System tests are automated and we can set them and forget them for the most part, but they cover a very small amount of test in the program as a whole.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

The Clean Coder (Week 4)

This blog post will consist of chapters 7 and 8.

Chapter 7 talks about how communication and avoiding communication errors between stakeholders and developers is imperative to the success of a project. The author emphasizes that the most effective approach to avoid miscommunication is to write automated acceptance testing.

Personally, I’ve never written tests for a corporation, but I have some experience with writing tests for small projects at my University. The tests that I wrote, were for a project that we had to work individually on, so there was never a time that miscommunication would occur.

Chapter 8 discusses all of the different testing strategies and how the most important goal for a development team is to have the quality assurance team find no bugs when they sift through the vast amounts of code. QA teams are important for a software, because without them, there will be plenty of bugs that weren’t discovered and this will effect the quality of the software dramatically.

 

 

From the blog CS@Worcester – My Blog by justcodeit94 and used with permission of the author. All other rights reserved by the author.

How to start EMR on AWS

NOTES FROM USING SPARK in the HADOOP ECOSYSTEM by Rick Morrow Starting EMR on AWS Objective In this lab, you’ll use Amazon Web Services to set up a 3 node Elastic MapReduce (EMR) cluster which you can then use for … Continue reading →

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

The Clean Coder, Chapters 7 & 8 Week 3 (2/14/17)

Chapter 7 of Clean Coders covers pretty much the scenario of both the developer and the business having different expectations or requirements where communication emphasizes clarity on what both sides want and expect to have. Other than that, the chapter also covers the concept of acceptance testing and how the author properly defines the term acceptance testing as “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”. While defining what done actually means, the author states that acceptance tests get the stakeholders, businesses and the programmer all on the same page since they all will know what the behavior of the program is going to be. Other than that the author talk about how the advantages of acceptance testing being automated is an advantage toward cost.

While personally I have never written tests that were automated before or even wrote programs for a business, i can not relate about having clients and working on their projects for them as well as the communication part. To be fair, I am programming in a team at the moment so I may get some kind of experience with that now but I do not know if we will be doing any automated testing.

Chapter 8 of  Clean Coders covers the aspect of having testing strategies. The big tip that the author notes is that the QA team should find nothing wrong when testing the developer’s software, and when they do find something developers may freak out about it. While the QA’s job is to find bugs, the testing strategies used by developers to make sure QA does not find any can include the test automation pyramid. The author takes time to describe this test pyramid as an effective way to test software. The automation pyramid includes (top to bottom) “M exploratory, System Tests, Integration Tests, Component Tests, and Unit Tests.

Personally I think its a challenge if developers have to be absolutely sure they flushed out all the bugs. If they do, then either QA isn’t trying hard enough to find bugs or they are missing some. While I commend there being requirements for developers to take part in to help make their code bug-free, I can highly doubt they can find and terminate all the bugs by themselves. I have not heard of a company that has a QA team that did not find any bugs at all because the developers were too good at debugging it themselves. Then again with the automation pyramid and other testing strategies, I could be wrong but I’m not ready to accept a world where QA people barely need to do anything and are considered non-useful.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.