Head First Software Development (2007)

[Darya Akbari]

Hi Bert,

the new HFOOAD book mentions a new Head First Software Development book for the year 2007.

Is that a type mismatch. I mean wasn't the HFOOAD supposed to be the Head First Software Development book .

If not, is there anything you can say about the Head First Software Development book.

Regards,
Darya

[Bert Bates]

HF Software Development is a different book than HF OOAD. The SD book is more about the processes and management aspects of SD. As this book shapes up we'll say more about it,

[Gian Franco]

Hi Bert,

Do you need an extra pair of eyes to review HF SD :-)

Kind Regards,

Gian

[Bill Mietelski]

Bert,

I'd be up for reviewing again as well.
The Software Development book sounds like another winner.

... Bill

[Darya Akbari]

Originally posted by Bert Bates:
The SD book is more about the processes and management aspects of SD. As this book shapes up we'll say more about it,

Can you say more? A pre-table of contents or the like?

[Bert Bates]

This book has been on a less critical path than several other books, so my info is out of date. I WILL get caught up on this title and get you guys some more info. We have a tight travel schedule for the next month, so I won't make any promises on when I get this feedback, but the book isn't that close to done, so I hope that wiating for the feedback won't cause any trouble

hth,

Bert

[Dan Pilone]

Hi all! I wanted to stop by and introduce myself. I'm the author of the upcoming Head First Software Development. Honestly, I was really suprised to see a topic started on this already on JavaRanch!

Anyway - as a teaser, some of the things covered in the book:

- Software Process (yes, a fun book about RUP & Agile... seriously.)
- Requirements (#1: Read this book)
- Testing (99% typo free)
- Coding, code reviews, etc.

I can't wait for this book to hit the shelves, but there's still time for some feedback if you guys have suggestions... -- Dan

[Darya Akbari]

Welcome to JavaRanch Dan ,

it's great to have you as the author of this next HF book here . Will your book stand against HF OO and HF PMP?. I would like to see a connection between all of them, at least a small one.

Regards,
Darya

[Darya Akbari]

Dan,

Another thing is how strong you handle the interrelation between Project Management and Software Development.

I see a very strong connection between Software Development and Project Management. They should somehow go hand in hand.

A very nice discussion is going on in this thread The Project Management mismatch?

The question here is how well you can merge Software Development with Agile Project Management and or PMBOK?

Regards,
Darya

[Darya Akbari]

Originally posted by Bert Bates:
The SD book is more about the processes and management aspects of SD.

I believe with management Bert means project management

[Dan Pilone]

Hi Darya,
Well, let me try to answer your questions this way: Make no mistake, this is a techinical book - I'm not afraid to use terms like classes, stubs, automated builds, unit tests, that kind of stuff. At the same time, obviously a lot of what makes a software project successful is project management - so that's a part of this book too. The book talks about requirements, use cases, prioritization of functionality, code reviews, etc.
So, where does this fit in the whole PMP, OOAD, Design Patterns scheme of things? I want to tie them all together - just like a Software Architect would for a software project. Software development means some project management, knowing what OOAD is all about, understanding where design (and architecture) patterns fit in and so on.
Does that help? -- Dan

[Darya Akbari]

Originally posted by Dan Pilone:
So, where does this fit in the whole PMP, OOAD, Design Patterns scheme of things? I want to tie them all together

This is exactly what I expect from this new HF book . No rehash of other HF books.

[Darya Akbari]

Hi Dan,

another thing I really want to see is that you show how to cope with an enterprise project. HF Design Patterns and HF OOAD do no enter these waters.

For example the Core J2EE Patterns are not handled in any of them.

I expect from HFSD to see the whole software lifecycle of an enterprise scale (J2EE) project.

The J2EE Patterns is something Bert promised a long time ago but never delivered. And when not in this book where you have the whole picture, where else do you want bring it ?

Regards,
Darya

[Bert Bates]

Hi Darya,

I remember discussing J2EE patterns on several occasions, but I don't recall ever promising that we'd cover those topics in a HF book. If I did promise that I apologize, it's definitely something we've discussed, but it's never been officially approved.

I will say that we like to discuss possibilities here at the ranch to help us gauge readers' interest in various topics, but please don't mistake a discussion for a committment.

Thanks, and sorry for any confusion.

Bert

[Darya Akbari]

Hi Bert,

Originally posted by Bert Bates:
please don't mistake a discussion for a committment.

To my understanding you promised it. Do you remember the Lost Capter in HFEJB . In several pages of HFEJB you point to that Lost Chapter.

How do you interpret you own statement from Questions reg exam and HFE:

Originally posted by Bert Bates:
We do intend to write a patterns chapter and it will be available on the wickedlysmart website as a free download. When the chapter is ready we will let everyone on this forum know, so stayed tuned!

Bert

And then again here HFEJB: Patterns and Performance, the Lost (last) Chapter:

Originally posted by Bert Bates:


Well you guys caught us! First off, we do apologize for never completing that chapter. Here's the real story...when we wrote the EJB book, the Head First series was brand new and we didn't really know if it was going to take off. We figured we'd have plenty of time to get back to that chapter "later" :roll:

So, long story short, we've been up to our eyeballs ever since - and it seems we're always late and behind schedule So, we're kind of forced to pick our battles, and although we've got some J2EE patterns on our list of things to do, so far other stuff has taken priority. Anyway, we ARE sorry, and it is on our list (now where did I put that list?)

Thanks for your patience!

- Bert

If that all is not a promise, then please accept my appologies. But lets not struggle over the word.

As I said before, if not here where else do you want bring that lost chapter . Or is J2EE also here out of scope

Regards,
Darya

[Bert Bates]

Hi Darya,

As I said before, I hadn't recalled making that promise, and I can see that saying it's "on our list" is a promise of sorts, so again, you have my apologies.

I will say that J2EE patterns is still a topic that is on our list, but I don't want that statement to be given too much weight. We're pursuing several approaches to creating learning materials, including the old standby, Head First, and at this point it's hard to know how everything is going to shake out.

What I can commit to is that we're very focused on figuring out how to make technical learning content more effective, and on how to make it easier for others to create that kind of good, quality content too. The goal is that we shouldn't be the bottleneck for HF kinds of material!

hth,

Bert

[Darya Akbari]

Hi Bert,

let's forget about the lost chapter (at least for now).

Is J2EE in scope of the new HFSD book?

Regards,
Darya

[Bert Bates]

Hi Darya,

I'll let Dan answer that question. I will say that as far as I'm concerned Dan is under no obligation to finish a "lost chapter" from a book that he had nothing to do with

hth,

Bert

p.s. I don't know if you've looked at HFSJ (which you can now do on Safari), but we do have a chapter on J2EE patterns in that book. I know that this isn't a complete answer to your request, but it is a start.

[Darya Akbari]

Originally posted by Bert Bates:
I'll let Dan answer that question. I will say that as far as I'm concerned Dan is under no obligation to finish a "lost chapter" from a book that he had nothing to do with

Of course Dan has no obligation for this all .

Ok, lets see the answer from Dan.

Regards,
Darya

[Dan Pilone]

Phew...

Ok - but seriously - how do you see J2EE (or, more specifically, J2EE patterns) fitting into this book? I would argue that a lot of the Software Development best practices apply regardless of whether your implement your system in J2EE, .NET, or even Perl-CGI. Sure, there are certain patterns you use when building a J2EE (MVC2, Stateless facades, etc, etc) but there are equally valid (and often different) patterns for different platforms.

So - hypothetically, if there was a J2EE Patterns chapter in this book, what would it look like? I do touch on Design Patterns and Architectural patterns and how they relate, but, truthfully, right now, I don't have any J2EE specific patterns in there. -- Dan

[Darya Akbari]

Hi Dan,

I am not talking about .NET or Perl here. It's obvious that at JavaRanch we more appreciate the Java way .

But let's get back to the main issue of J2EE. Do we live in 2007 or not? Are we nowaday more involved with enterprise scale applications than with any other form of application or not?

What is so strange with handling J2EE? You do so (like HFOOAD and HFDP) as J2EE is a no go area. And the arguments from different people reach from "Too easy" to "Too hard".

Maybe the next image make things a little bit more tangible. The image show a simple example from the Core J2EE Patterns book for an order processing system.



Do you see all these hidden J2EE Patterns in it? There you have: Business Delegate, Service Locator, Session Facade, Application Service and plain Domain Objects (POJOs).

Now as a result from a Requirements Analysis you have a list of requirements or features or whatever one calls them. One requirement is for example to place an order. Now look the image and how this placeOrder is piped through this J2EE Architecture.

Saying that one can extend these Patterns herself from the wellknown GoF patterns is making things a little bit too easy .

I think the example says a lot. How can you say that J2EE Patterns is not an issue in Software Development. .

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
I am not talking about .NET or Perl here. It's obvious that at JavaRanch we more appreciate the Java way .

I don't think we can expect every published book to be about Java, though. To me, a book about "software development" sounds to me as if it should very much be platform agnostic.

But let's get back to the main issue of J2EE. Do we live in 2007 or not?

Sure.

Are we nowaday more involved with enterprise scale applications than with any other form of application or not?

And even if "we" are (which is not totally obvious to me), what does that tell us about the "correct" content of a book about "software development"?

What is so strange with handling J2EE? You do so (like HFOOAD and HFDP) as J2EE is a no go area.

I think Bert made it very clear that it is *not* a "no go area". I don't see how it being a valid topic for a book in general makes it a good topic for this book (or the other existing ones), though.

[Michael Farinha]

Just to comment from another perspective. I am very much interested in this book (and every other HF book!) however the development I do is in .NET. I can read Java just fine and translate it to suit my needs. Having a book titled "Head First Software Development" I would expect a well rounded book that I can read and use regardless if I am designing an enterprise application or a simple Intranet web application. Also I would expect the book to be equally useful whether I am using .NET or Java.

If the book doesn't mention J2EE anywhere on the front cover I'd be disappointed if I purchased it and then later found out that I couldn't apply the concepts in the book.

The great thing I like about the Head First series is that the topics cover foundational concepts. Once you learn these foundational concepts you are better prepared to move on to specifics in your particular area of study/practice.

Darya, I think the book you are waiting for is "Head First J2EE Design Patterns"
[ March 27, 2007: Message edited by: Michael Farinha ]

[Darya Akbari]

Hi Michael,

it takes a lot of energy to shift around J2EE and not handling it. I understand your feelings toward HF and Java when you come from .NET. But weren't all of them somehow Java based because Kathy and Bert come from Java?

My impression is more that this is all intentionally. Maybe to come with a next Head First J2EE Patterns book as you hint .

Regards,
Darya

[Darya Akbari]

Originally posted by Ilja Preuss:
I don't see how it being a valid topic for a book in general makes it a good topic for this book

Why not, you stopped right there where it becomes interesting . Here again:

Originally posted by Darya Akbari:
Maybe the next image make things a little bit more tangible. The image show a simple example from the Core J2EE Patterns book for an order processing system.



Do you see all these hidden J2EE Patterns in it? There you have: Business Delegate, Service Locator, Session Facade, Application Service and plain Domain Objects (POJOs).

Now as a result from a Requirements Analysis you have a list of requirements or features or whatever one calls them. One requirement is for example to place an order. Now look the image and how this placeOrder is piped through this J2EE Architecture.

Saying that one can extend these Patterns herself from the wellknown GoF patterns is making things a little bit too easy .

I think the example says a lot. How can you say that J2EE Patterns is not an issue in Software Development. .

Doesn't it make sense ?

Regards,
Daryax

[Bert Bates]

Hi Darya,

I think that "HF J2EE Patterns" would make a fine book

Bert

p.s. However, that doesn't mean that we have the resources to create that book right now. We have a long list of topics that we think would be great to write about.

[Darya Akbari]

Originally posted by Bert Bates:
I think that "HF J2EE Patterns" would make a fine book

Hi Bert,

be sure that I'll be the first one in Germany who will pick up one copy of it .

I would appreciate when you or Dan can comment on the example I gave (see my last post).

Regards,
Darya
[ March 28, 2007: Message edited by: Darya Akbari ]

[Michael Farinha]

Hey Dan,

I had a quick question. How much code will be in this book? Also will it be like HFOOAD and HFDP will all code samples in Java?

Just curious.

Thanks!

[Dan Pilone]

Phew - I don't read the forum for a day and I end up falling behind.

Ok, first, Darya - I completely agree that J2EE patterns classify as Software Development issues, but so do a ton of things. While you may not be working in the .NET or Perl (or Ruby or ...) space, all of those languages would fall in the Software Development space too.. So would Olog(n), NP-Complete, etc, etc. I feel it's my job as the HFSD author to try and distill the essential SD issues that would apply to the broadest audience. I don't want to dilute the topics so much that there's no take away value, but at the same time there is so much commonality that I can easily fill a HF book without getting into specific platform patterns.

Given your image, sure, there are lots of patterns in there: there are J2EE patterns (which are really just J2EE realizations of extensions of some of the basic GoF patterns, but I digress) - there are also implicit architectural patterns and basic OOAD patterns. Futhermore, there's implicit UML understanding, and software modeling and design, etc, etc. There's a _ton_ of information in just that small diagram - hence the power of the whole visual HF approach, but I digress again. Anyway, my point is: I don't want to minimize the importance of J2EE (it's actually what I'm doing in my day job right now) but there are so many other important SD topics that J2EE patterns may be better treated by a book that can dedicate appropriate space to do it justice.

Michael - there is some code in the book - it really depends on the chapter. For instance, the Testing chapter has a decent amount (though more pseudo-code than real "bust out your compiler" kind of code) as does the design chapter (ironic huh?) and of course the implementation chapter. On the other hand I don't think the Requirements or Software Process chapters have any...
As for the language, yes, I used Java. Honestly, there are almost no Java-isms in there, so with a trivial amount of squinting you could pretend it's C#. It's definitely not VB or Perl though... no amount of squinting would get you to think that. I picked Java because it is so common. Even if you're not a Java developer you can more or less make out what it's supposed to represent. Since I'm not heavily focused on actual code I didn't see an advantage to picking another language. I toyed with the idea of switching languages between chapters but again, couldn't really come up with an advantage other than avoiding an Amazon review that says something like "This book rocks - even though the examples are in Java." -- Dan

[Devender Thareja]

Hi Dan/Bert,

I am very eager to buy this book. When will it be available?
It would be nice if you can put a chapter about effective documenting system architecture at various stages of life cycle of project and supposed life of those documents. I mean, is there any point in keeping requirements document after the system is delivered? At the same time a design and an architecture document is always useful. But how much minimum detail should go in each document to keep it effective and easy to maintain.
A proponent of Agile methodology will suggest that documents can easily get out of sync with the system as system evolve, hence no separate document should be done. And I see that they have a point. It would be nice to have a conclusive chapter on this.
To summarize my wish list item: how many type of documents? At what stage? How long to keep/maintain them? What should be minimum content of each document?

Thanks.

[Darya Akbari]

And I thought this one will be with a cover girl .

[Glenn Timchishen]

woah... has anyone checked out amazon.com lately? HFSD has been pushed back to dec 2007??? What happened? I'm preparing myself to develop a spring/hibernate app in my own time for personal career dev and this would have been awesome (as I loved HFOOA and i'm about to start HFDP) but I'm not sure if I will read it as by december i'll have learned everything this book has to offer... the hard way. (I was hoping i would have able to do it the easy way, by reading that book)

I know it's probably a sore subject but I would be interested in details if anyone is willing to share...

[Bert Bates]

In a nutshell, you guys are a demanding audience (that's a good thing!)

We liked what we had created, but upon a more detailed review we concluded that we needed to dive more deeply into a lot of the topics we cover in the book. So, even though we wish we could be relatively "on time", we agreed that the proper depth was more important. I want to congratulate O'Reilly for making this really tough call. IMHO, it's great to see an organization make a decision to favor quality over revenue.

So, bear with us while we add a couple of hundred pages to this baby!

Thanks,

Bert

p.s. I will say that HF SQL is looking really good and should be ready to print pretty darned soon!

[Ilja Preuss]

Originally posted by Glenn Timchishen:
I'm not sure if I will read it as by december i'll have learned everything this book has to offer... the hard way. (I was hoping i would have able to do it the easy way, by reading that book)

Well, from personal experience, I can tell you two things:

- you will never stop to learn - in fact, every year again you will wonder how few you actually knew a year ago, and there will always be another book (or article, interview, whatever) that will give you new important insights

and

- no matter how great and helpful a book is (and I'm sure HFSD will be great), it will never be *easy*

[Glenn Timchishen]

Thanks for the info, i'm sure alot of people are thankful for that info.

I guess in my previous post I should have said easier, not easy.


the project i'm intending to do is kinda difficult as its meant to teach me things regarding software dev with java/spring/hibernate. I'm running into the problem that I have to learn certain things to start the project so i've read like 5 books. I don't want to go and create something only to realize that i've created garbage due to not being knowledgeable on a certain subject. But on the other hand... you can't read books forever... eventually you just need to dive in.

comments? What do you do on a software dev project when you are faced with a chicken and the egg problem?

[Raghavan Muthu]

HF series always rocks irrespective of the area of focus!! thats for sure!!

[Michael Farinha]

it's great to see an organization make a decision to favor quality over revenue.

I concur, this is one of the main reasons I love the Head First series!

Please take your time

[Darya Akbari]

Here an update from Amazon.com:

Delivery estimate: January 8, 2008 - January 22, 2008 1 of: Head First Software Development

Regards,
Darya

[Darya Akbari]

See an interview by the authors at headfirstlabs.com.

[Dan Pilone]

We're still here! Sorry for the silence but to say we've been heads down is an understatement. As Bert mentioned the book slid a little but I can say without any hesitation it is so much better for it. As Darya mentioned Russ & I have a short interview on Head First Labs that will give you a more insight into the thinking that went on behind the book.

I think everything we've talked about earlier in this thread is stil true except with even deeper coverage. This book is about writing software - the serious, get your hands dirty, professional software development that gets results.

I can't wait until you guys get the book in your hands - it's been an amazing process to put it together. -- Dan