1) PeopleWare - Productive Projects and Teams.
How to build a product - which most of the time boils down to how to build a great team and manage them. I will paraphrase Joel Spolsky's review of the book here, since it correctly summarizes what you will get out of this book.
"As summer interns at Microsoft, my friends and I used to take "field trips" to the company supply room to stock up on school supplies. Among the floppy disks, mouse pads, and post-it notes was a stack of small paperback books, so I took one home to read. The book was Peopleware, by Tom DeMarco and Timothy Lister. This book was one of the most influential books I've ever read. The best way to describe it would be as an Anti-Dilbert Manifesto. Ever wonder why everybody at Microsoft gets their own office, with walls and a door that shuts? It's in there. Why do managers give so much leeway to their teams to get things done? That's in there too. Why are there so many jelled SWAT teams at Microsoft that are remarkably productive? Mainly because Bill Gates has built a company full of managers who read Peopleware. I can't recommend this book highly enough. It is the one thing every software manager needs to read... not just once, but once a year".
2) Building a successful Software Business.
This is a book about selling the great product you already built. Everything you need to know about marketing/selling a software product - in fact anything other than building the product itself.
- Do you wonder what goes on after you build the product?
- Does the word marketing, run circles around your head.
- Do you know the various channels through which you can market your product
- Want to know how to evaluate a sales pipeline - and factor it into your projections.
- What cashflow is and how to manage it.
- If so, this book is for you. It is a bit dated(written in 1993) ; However as anyone ever been in business knows - the business aspects of a business don't really change that much.
3) The third book is a great book by Rod Johnson from Interface 21, regarding the development of Java Web Applications - without using EJB.
Ever since I have been looking at EJB from some years ago, I have been wondering
- Why all this verbosity?
- Why so many constraints on where my objects should inherit from?
- Why so much emphasis on EJB and components - instead of pure Objects? What happened to Java being Java?
- Why so much repetition, everywhere?
- Why so many transfer Objects everywhere?
- Why is so much type casting, which defeatsthe whole purpose of Java's strong typing?
- Why so much glue code to connect/wire services/components
- Why so much emphasis on RMI?
- Why do I need to deploy to test a "Hello World"?
- Having been trained in C and Assembly during my college days, I was wondering why so much emphasis to dumb down programming and drive everything from XML files.
Then I started playing with light-weight frameworks and understood the motivations of EJB and how things can be simplified. I have been postponing reading this book for a long time and finally got my motivation to pick it up .