Chapter 7

One of the main
reasons to implement an Agile environment I believe is that you are
constantly reviewing and re-tooling the process to make it work in an
efficient manner. I like how he opens with something similar to this
and says something to the effect of not being tied down to a heap of
documents and diagrams that were written a century ago. Technologies
change fast today so what may have been good yesterday may not be
good today, literally. In the author’s words Agile development
provides a “quick, short feedback loop”. I understand, but I
don’t understand why all companies don’t use extreme programming
practices. He says that in one company they noticed a 1/3 reduction
in production bugs. That is amazing and saves the company a lot of
cash and it’s amazing that companies seem to value it so little as
far as the book says anyway. I like his stance on how to convince a
manager to use the practices by promoting the value of the
methodology instead of the practice of it. That is good advice.
Another thing that I was surprised by was the efficiency of automated
testing, I mean I know that is a time saver and all that, but I
didn’t realize the scale of its goodness. It does make sense though
because as he says, “as the system grows so do the number of
tests.”. Writing them before hand is a time saver and also gives
you something to code to. I am not going to go into the rest of the
chapter because it is a repeat of the Clean Coder. Test Driven
Development, Refactoring, Pair Programming, Refactoring, Continuous
integration, yada, yada, yada. I find that the book has its good
points, but it is a lot of Clean Coder and I think that either one or
the other should be read, but certainly not both in my opinion.

Chapter 8

This chapter brought
back memories of me and my good ole commodore 64 chopping away at te
keys in basic. I only wish I had stuck with it back then, but I am
glad that I got back to my roots and got back into it again. I think
out of all of the chapters I relate to this one the most, but on a
personal level. I like the Yogi Berra quote, “ You’ve got to be
careful if you don’t know where you’re going because you might
not get there.” I thought I was doing what I loved at my last job
until I got hurt that is. Then I was in a whole new situation and I
didn’t like it. I am finally at the point that I know what I want
to do and am happy with the decision, but it took a while to get
here. I have been and am using a lot of his tactics. Expanding
technical knowledge, attending user groups, and networking to name a
few and they have been fantastic to me. Like he says a career is an
investment. I am glad I am a bit older and have gained a lot of
wisdom along the way so the process of changing careers has been ok,
scary in a way but ok. I am doing what I love and can’t wait to put
it into practice.

Chapter 7

One of the main
reasons to implement an Agile environment I believe is that you are
constantly reviewing and re-tooling the process to make it work in an
efficient manner. I like how he opens with something similar to this
and says something to the effect of not being tied down to a heap of
documents and diagrams that were written a century ago. Technologies
change fast today so what may have been good yesterday may not be
good today, literally. In the author’s words Agile development
provides a “quick, short feedback loop”. I understand, but I
don’t understand why all companies don’t use extreme programming
practices. He says that in one company they noticed a 1/3 reduction
in production bugs. That is amazing and saves the company a lot of
cash and it’s amazing that companies seem to value it so little as
far as the book says anyway. I like his stance on how to convince a
manager to use the practices by promoting the value of the
methodology instead of the practice of it. That is good advice.
Another thing that I was surprised by was the efficiency of automated
testing, I mean I know that is a time saver and all that, but I
didn’t realize the scale of its goodness. It does make sense though
because as he says, “as the system grows so do the number of
tests.”. Writing them before hand is a time saver and also gives
you something to code to. I am not going to go into the rest of the
chapter because it is a repeat of the Clean Coder. Test Driven
Development, Refactoring, Pair Programming, Refactoring, Continuous
integration, yada, yada, yada. I find that the book has its good
points, but it is a lot of Clean Coder and I think that either one or
the other should be read, but certainly not both in my opinion.

Chapter 8

This chapter brought
back memories of me and my good ole commodore 64 chopping away at te
keys in basic. I only wish I had stuck with it back then, but I am
glad that I got back to my roots and got back into it again. I think
out of all of the chapters I relate to this one the most, but on a
personal level. I like the Yogi Berra quote, “ You’ve got to be
careful if you don’t know where you’re going because you might
not get there.” I thought I was doing what I loved at my last job
until I got hurt that is. Then I was in a whole new situation and I
didn’t like it. I am finally at the point that I know what I want
to do and am happy with the decision, but it took a while to get
here. I have been and am using a lot of his tactics. Expanding
technical knowledge, attending user groups, and networking to name a
few and they have been fantastic to me. Like he says a career is an
investment. I am glad I am a bit older and have gained a lot of
wisdom along the way so the process of changing careers has been ok,
scary in a way but ok. I am doing what I love and can’t wait to put
it into practice.

Chapter 7

One of the main
reasons to implement an Agile environment I believe is that you are
constantly reviewing and re-tooling the process to make it work in an
efficient manner. I like how he opens with something similar to this
and says something to the effect of not being tied down to a heap of
documents and diagrams that were written a century ago. Technologies
change fast today so what may have been good yesterday may not be
good today, literally. In the author’s words Agile development
provides a “quick, short feedback loop”. I understand, but I
don’t understand why all companies don’t use extreme programming
practices. He says that in one company they noticed a 1/3 reduction
in production bugs. That is amazing and saves the company a lot of
cash and it’s amazing that companies seem to value it so little as
far as the book says anyway. I like his stance on how to convince a
manager to use the practices by promoting the value of the
methodology instead of the practice of it. That is good advice.
Another thing that I was surprised by was the efficiency of automated
testing, I mean I know that is a time saver and all that, but I
didn’t realize the scale of its goodness. It does make sense though
because as he says, “as the system grows so do the number of
tests.”. Writing them before hand is a time saver and also gives
you something to code to. I am not going to go into the rest of the
chapter because it is a repeat of the Clean Coder. Test Driven
Development, Refactoring, Pair Programming, Refactoring, Continuous
integration, yada, yada, yada. I find that the book has its good
points, but it is a lot of Clean Coder and I think that either one or
the other should be read, but certainly not both in my opinion.

Chapter 8

This chapter brought
back memories of me and my good ole commodore 64 chopping away at te
keys in basic. I only wish I had stuck with it back then, but I am
glad that I got back to my roots and got back into it again. I think
out of all of the chapters I relate to this one the most, but on a
personal level. I like the Yogi Berra quote, “ You’ve got to be
careful if you don’t know where you’re going because you might
not get there.” I thought I was doing what I loved at my last job
until I got hurt that is. Then I was in a whole new situation and I
didn’t like it. I am finally at the point that I know what I want
to do and am happy with the decision, but it took a while to get
here. I have been and am using a lot of his tactics. Expanding
technical knowledge, attending user groups, and networking to name a
few and they have been fantastic to me. Like he says a career is an
investment. I am glad I am a bit older and have gained a lot of
wisdom along the way so the process of changing careers has been ok,
scary in a way but ok. I am doing what I love and can’t wait to put
it into practice.

Well this past sprint went well. Issue NGPOC-185 was successfully fixed and our pull request was accepted, tested, and put on the live test build which is awesome. I learned a good amount by reviewing the code and trying to figure out the issue, though in the end Dan solved it. I have found it quite the experience so far. After completion of NGPOC-185 we decided to split into 2 teams which was for the better because it seems like a lot of the issues don’t need 6 people working on them, but for a start it worked out well as we were getting our feet wet. We chose issue APTS-159 to work on which they wanted the list in a form to show in order of date, newest to oldest as it was supposedly backwards. After investigating the issue and implementing a solution we found out that issue had already been fixed. Brings back memories of people not closing tickets and wasting time. In this scenario it was a learning experience, but in the real world time is money and this would have cost the company a few bucks. It is kind of nice though to see the process working and having to dig through code to figure out where an issue lies and then figure out how to implement a solution. I love troubleshooting.

We are now on 2 issues, one as our split group of 3 and the other as a whole team. We will probably only get one done possibly because time is running short. The first issue is AA-680 which is “Can’t add child to parent relationship”. The problem we believe lies in the database which we do not have access to so we are waiting on an answer from OpenMRS on this. We have found where the relationship lies in the code, but cannot do anything until we get an answer. The issue is that there is only a parent/child relationship and no child/parent relationship. In other words if a child is seen at the clinic, there is no way to add a parent to the form in the relationship drop down. It seems like in this industry, or at least this project there is more time spent waiting on clarification than anything. I understand there are different time zones and such but it sometimes seems counter productive. I guess though you can have multiple issues signed out and at least there is communication. I feel like I am learning more about how the process works than actually learning Angular, not that I am not learning Angular I just guess I thought it wold be different. That is the beauty of it though I guess.

The next issue we are now working on as a team is APTS-254 and they want a reminder to pop up 6 months after switching to a new ART line. This is another issue we are currently waiting on answers for . We have nailed down the area it is in and it seems like we need to just implement a reminder function possibly, but once again we are waiting on clarification, so it’s the hurry up and wait game I guess. It isn’t anyone’s fault it just gets frustrating because we all want stuff now and that isn’t how the world works. I feel confident that I can look at a project now and understand how things work and figure out the routing and logistics of it and that feels good. I am glad I have been able to have this experience and hop that we can get one more issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.  

Well this past
sprint went well. Issue NGPOC-185 was successfully fixed and our pull
request was accepted, tested, and put on the live test build which is
awesome. I learned a good amount by reviewing the code and trying to
figure out the issue, though in the end Dan solved it. I have found
it quite the experience so far. After completion of NGPOC-185 we
decided to split into 2 teams which was for the better because it
seems like a lot of the issues don’t need 6 people working on them,
but for a start it worked out well as we were getting our feet wet.
We chose issue APTS-159 to work on which they wanted the list in a
form to show in order of date, newest to oldest as it was supposedly
backwards. After investigating the issue and implementing a solution
we found out that issue had already been fixed. Brings back memories
of people not closing tickets and wasting time. In this scenario it
was a learning experience, but in the real world time is money and
this would have cost the company a few bucks. It is kind of nice
though to see the process working and having to dig through code to
figure out where an issue lies and then figure out how to implement a
solution. I love troubleshooting.

We are now on 2
issues, one as our split group of 3 and the other as a whole team. We
will probably only get one done possibly because time is running
short. The first issue is AA-680 which is “Can’t add child to
parent relationship”. The problem we believe lies in the database
which we do not have access to so we are waiting on an answer from
OpenMRS on this. We have found where the relationship lies in the
code, but cannot do anything until we get an answer. The issue is
that there is only a parent/child relationship and no child/parent
relationship. In other words if a child is seen at the clinic, there
is no way to add a parent to the form in the relationship drop down.
It seems like in this industry, or at least this project there is
more time spent waiting on clarification than anything. I understand
there are different time zones and such but it sometimes seems
counter productive. I guess though you can have multiple issues
signed out and at least there is communication. I feel like I am
learning more about how the process works than actually learning
Angular, not that I am not learning Angular I just guess I thought it
wold be different. That is the beauty of it though I guess.

The next issue we
are now working on as a team is APTS-254 and they want a reminder to
pop up 6 months after switching to a new ART line. This is another
issue we are currently waiting on answers for . We have nailed down
the area it is in and it seems like we need to just implement a
reminder function possibly, but once again we are waiting on
clarification, so it’s the hurry up and wait game I guess. It isn’t
anyone’s fault it just gets frustrating because we all want stuff
now and that isn’t how the world works. I feel confident that I can
look at a project now and understand how things work and figure out
the routing and logistics of it and that feels good. I am glad I have
been able to have this experience and hop that we can get one more
issue pulled up before the end of the semester which is soon.