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.  

I have to say it seems like just after I get done with a decent chapter I move on to the next and boom! You can tell that this is an Uncle Bob series book. I am so tired of hearing the word professionalism and professional that I want to puke. I am going to keep this chapter’s blog short. Maybe it is because I have been through a lot of the scenarios he talks about that I get irritated. This chapter is almost exactly like a chapter that Bob wrote in the clean coder. Never say I’ll try and get it done because the boss takes that as you will, don’t over exert yourself or you’ll get burnt out, you can’t code good at 3am, sleeping in the parking lot and getting a horrible nights sleep is a bad idea etc. I get that it is important to learn how to say no, and not commit to something you know you can’t deliver even if it means getting that nasty look from your boss or a guilt laden trip from hell. I just think it is over done in the series. I understand that important things need to be reinforced, but I think it is over done here. I will stop ranting now, because the book does have its good points, I just am not fond if certain chapters.

I do have to say that this book seems to alternate good and bad chapters to me. This chapter I thought was informative and had some useful stuff. I agree with these guys on their stance of having clean code and working software, or being a software craftsman if you will. He hits on many things in this chapter and something stood out to me right off the bat. He said that “some organizations believe that with a good management team, deep hierarchies, micromanagement, strict process and a large amount of good documentation and the project will succeed.” One other line was that many organizations see developers as lesser skilled than the higher qualified managers. He hit the nail on the head with those two statements. I have seen this in most every industry I have worked in. They always seem to forget that us underlings are the cogs that keep the machine turning. That is not to say that good management isn’t important, I just think there is a lot of backwards thinking and it is maybe because they pay the management ludicrous numbers and they need some way to justify it?

I also thought that his stance on working software is not enough was well done and very true. I think there are a lot of hacks in every trade that thinks that good enough is ok. I firmly believe that you should take care of your code like you are looking after your garden. It needs to be weeded and groomed and fed to ripen and blossom. It is like a living being it seems to me. Especially after working on the Ampath project and seeing how projects work and the communication and all of the collaborators working together. He says the cost of dealing with bad code can make companies less competitive and I agree. It reminds me of a saying my father used to say to me, “Don’t do it half ass because you’re just going to have to do it over again and it will take twice as long as if you’d just done it right in the first place.” I can’t argue with that wisdom as I found out the hard way a few times more than I care to admit.

Over all I really enjoyed this chapter and took away some things from it. I really hope that I don’t end up working for a company like some of the nightmares he was talking about. So much about Agile development makes sense and on paper is grand, I just hope that at least some of the methods are employed when I get out there.

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.