Alex V (4) [Avatar] Offline
#1
Hi,

first off, thank you for the effort you're putting in this book and opening it up for MEAP.
I have only read the first chapter so far, and will continue to read the rest in the coming days/weeks. Realizing chapter 1 is the introduction to the rest of the book (getting people to understand most of the full scope of problems with software development is tricky), I have a few notes and questions on some of the paragraphs.


On page 9:
The one but last paragraph details a short story, where a rather "light atmosphere" is created around a problem use case.
Although it was already said in the book that there is more to it than the technical debt, which is indeed completely correct. The light atmosphere on that paragraph however, does not emphasize the core of the problem with the described situation. Which is bad *-
-Process
-Planning
-Architecture
Maybe inserting some key sentences or nuances could make the reader understand that is not only the developer's fault.

Page 12:
The stages of delivery are a valid point. There is a nuance in the one but last paragraph which I believe to be misleading. Correct me if I'm wrong, but that paragraph is written as if the multi-stage setup is already in place, and does not require reverse-engineering, only maintenance.
It is written that devs should mimic the production environment, as a good practice I would actually advise the opposite. Architects pick and match components as they see fit, devs need a way to deploy it to their local machines, ops need the same. The projects I've been on that were the most successful is if the devops guys actually used much of the same tools as the devs were using. This made sure that the developers were contributing in multiple ways: maintaining the system(s) and maintaining the supporting system(s). Of course, the fact that your production environment can evolve in a different way than the testing and developer environment still stands.

If my original assumption is wrong, and this paragraph is about reverse-engineering the system, then that nuance is correct.

Page 15:
On the table on the top of the page, the "change" to "benefit vs risk" and "action required" is detailed. I know you only have a limited space, and maybe you will go into depth in later chapters. But I think it interesting to also know when you can do those things. On a personal opinion a factor of 10 or square root reduction in complexity is a trigger for me to refactor the code. If the complexity does not go down enough, don't touch the code.

Page 16-17:
Summary
Indeed the first chapter is a nice overview of most of the issues in software land. I do believe the project and architecture side is not emphasized enough. I realize the book is not about architecture nor about project structure or design. However most of what you will describe in future chapters is in fact part of the architect's job (to organize, guide and orchestrate), so it is quite possible that they will become a large part of your buyers.

A reason I decided to buy the book is because it was said to be process-agnostic, there are too many books and writers out there that confuse agile development with... just about anything. If you are worried about adding terms such as architect or project manager, I would not be. Even agile teams have an architect (they usually call him lead developer or sometimes the scrum master role), and most have project managers too. Granted the role architect is a bit overused and lead developer is a more neutral term.



I am looking forward to reading the next chapters, thanks again for your efforts.
chris.birchall (13) [Avatar] Offline
#2
Hi Alex,

Sorry for the slow reply, and thanks for the detailed feedback!

It sounds like there are a few places where I am not making my meaning clear. I'll make sure to read over the chapter again with your feedback in mind, and see if I can clear some things up.

Chris
Alex V (4) [Avatar] Offline
#3
Thanks, looking forward to it smilie.
mangelo (22) [Avatar] Offline
#4
Enjoying chapter one so far. Looking forward to other chapters as the book progresses. This is a very, very small point, but where you mention about the directory of the images:

We'll have to use , and good luck getting the/var/data tests to run on Windows!

This will work on Windows, but the directory would have to be created from the C drive (ie. C:/var/Data). The way its worded, it sounds like this isn't possible on Windows at all, but I do agree that none of the hard-coding should be there.

Mike
chris.birchall (13) [Avatar] Offline
#5
mangelo wrote:Enjoying chapter one so far. Looking forward to other chapters as the book progresses. This is a very, very small point, but where you mention about the directory of the images:

We'll have to use , and good luck getting the/var/data tests to run on Windows!

This will work on Windows, but the directory would have to be created from the C drive (ie. C:/var/Data). The way its worded, it sounds like this isn't possible on Windows at all, but I do agree that none of the hard-coding should be there.

Mike


Thanks Mike, this shows how much I know about Windows! Somebody else mentioned this. I'll fix it.