Alexis Smirnov: Alexis Smirnov > books

Beyond Software Architecture by Luke Hohmann

Mon, 30 Jun 2003 14:04:29 GMT

Beyond Software Architecture by Luke Hohmann.

I bought this book based on several factors. First of all, I think that learning more about interrelationships between marketing and software engineering should be important for anyone interested in creating successful software products. Secondly, I’ve found that the first book in AW Martin Fowler Signature Series (Patterns of Enterprise Application Architecture) a must-have reference for every serious software architect.

When I first opened this book I was very impressed by the number of high-profile people endorsing it and giving it praise. Exited, I’ve said to myself and others that I have great expectations for this book – I will learn a great deal from unique experience of the author. After all, not every author can speak from the position of software architect, product manager, marketing professional, software developer, development manager, consultant and teacher.

When I started reading, I began to notice that statements made by the author were correct, but often too simplistic, trivial or incomplete. Not to worry – I though to myself. The author must be preparing the reader for in-depth insight on “how to build winning solutions”. So I’ve continued reading.

By the third of the book I’ve stopped taking this thing seriously. I’ve realized that the author has chosen to touch on every single topic relevant to a software development organization. The trouble is, the author fails to tell anything that would not be considered trivial by any experienced software professional. Opening the book at random you’d stumble on sentences such as “The business plan distinguishes itself from all other development documents at it is the foundation for all the work associated with the product.” Correct, but fairly content-free.

And then, there are numerous text boxes that break-up the prose by telling a story from author’s experience. Most of those stories tell about how the author single-handedly saved the day by being super clever, super insightful and generally super smart. Great stuff for someone who considers hiring the author, but most of those examples bring little in terms of in-depth analysis of the issue.

The bottom line is, if you’ve spend a few years developing commercial software – don’t bother reading this book, you probably already know the things this book talks about. And if not, you’ll be much better off picking a more focused book that covers a particular topic of interest. Would I recommend this book to a student? No. In fact, the book is even less useful for a student because it covers too broad of an area without giving the reader in-depth knowledge in anything. Perhaps the only case where the book would be useful is for someone who wants a high-level overview of the issues that architects, senior developers and product managers worry about.

One good thing that this book introduces (in appendix) is the idea of using patters for things beyond software design. The idea of capturing “design patterns” for business and marketing issues isn’t new, but definitely not completely explored or understood.

The book attempts to close the gap between business and technology. Not many people have had the right experience to do so and be able to write well about it. The best (even a bit dated) book I’ve read on the subject remains “High-Tech Ventures” by Gordon Bell.

Fri, 25 Apr 2003 13:14:47 GMT

The value of any ontology can be measured by the number of applications that use it. GOF book represents of the best introduction of a new ontology i've seen so far. By now design pattern terminology as defined by this book is firmly embedded in developer's vocabulary.

Take Cooper's seminal book "About Face: The Essentials of User Interface Design" for example. Cooper defined a rich and comprehensive set of terms to describe elements and concepts of user interface. Fast forward a couple of years. Have you heard any developer say "But out application is sovereign! Why do we start it pluralized???" Very few people talk about user interface in terms of Cooper's ontology.

I have great expectation about Fowler's book on patterns of enterprise architecture. I think Fowler's ontology of enterprise patters has a real chance of becoming integral part of vocabulary of enterprise developers. It is great to see MSDN patterns site (via Harry Pierson) running with Fowler's ontology.

Organizing Genius: The Secrets of creative collaboration

Mon, 31 Mar 2003 13:35:33 GMT

Organizing Genius: The Secrets of creative collaboration (on amazon.ca)

This book explores common treats of what author calls a "Great Group". The book tells stories of a dozen groups that created breakthroughs in many different domains from creation of the first Disney’s animated feature film, to the development of first Apple computer. Authors uncover and show characteristics of Great Groups using numerous and at times repetitive examples. The last chapter summarizes the lessons.

I’ve been lucky to find some of characteristics of Great Groups in best teams I was involved with. I think that one of the best goals a manager can set for himself is to make his group closer to being a Great Group. It is certainly one of my biggest goals as a manager of software development team.

I have a mixed feeling about this book. Even though I’ve found messages contained in this book to be extremely valuable, I don’t think authors have chosen the best way to present them. Most of the volume of the book is taken by numerous stories about how a particular group worked. Many of the tales add little to the core message of the book and merely dissolve that message in irrelevant material. My advice the author: the title of this book should have been "Organizing Genius. Stories of creative collaboration". Or even better – instead of writing the book authors could have written a fantastic article that spells out all the same points without wasting reader’s time. Pretty much every chapter digests other sources, so if you’re interested in each particular group, I think you’ll find much better accounts elsewhere.

Here’s how I would summarize the lessons. I feel they are all important, but I’ve tried to put them in order of importance:

1. Great Groups start with superb people. In Great Groups the golden rule "hire good people" is pushed to the extreme.

2. Great Groups made of people who can work together. Great Group will not happen if it is made of geniuses, but they cannot work together towards the shared goal.

3. Every Great Group has a strong leader. Great Groups don’t need leaders to be saints, but they require for leaders to be absolutely thrustwordy as far as project is concerned.

4. Great Groups are extremely focused on the project at hand. The project is all they see.

5. Great Groups ship. Such groups are inherently action oriented. Even though people thoroughly enjoy the creative process, everyone if focused on one single thing – end result.

6. Leaders of Great Groups give them what they want and free them from the rest. People in Great Groups have the right tools, they have the right working environment, they are spared from bureaucracy and excise.

7. In Great Groups the right person has the right job. In such groups people are not interchangeable. They feel that they are the only once in the universe who can do the job.

8. Great Groups see themselves as winning underdogs. Great Groups don’t merely produce the product – they "win".

9. Great Groups always have an enemy. The group cannot "win" without having a natural or manufactured enemy.

10. Great Groups think they are on a mission from God. Great Groups don’t just produce something – they are "making a dent in a universe".

11. Every Great Group is an island – but an island with a bridge to the mainland. It is the job of the leader to create island and to be that bridge.

12. Great Groups are optimistic, not realistic. This is how such groups are able to do what others say cannot be done.

13. Great work is its own reward. Vast majority of people involved in a Great Group did so not because of money, but because of the insane fun they had in the process.

Fri, 28 Mar 2003 12:57:31 GMT

Ordered Essential ASP.NET With Examples in C# (on amazon.ca) primarely based on rave reviews of wellow webloggers as well as the fact that every single book from AW .NET series was worth the money. This book did not disappoint.

Fritz has found the right to mix of giving the reader the theory and practical advice. The author assumes that the reader is familiar with .NET and is experienced in application design (I soooo wish more authors would make the same assumption!).

This book gives an experienced developer enough background to be able to make some of the most important design decisions such as when and how to separate presentation logic in custom controls; how to manage state; what data caching option to use etc.

The flow of Essential ASP.NET is absolutely impeccable. Every detail and feature of the technology is introduced at exactly the right place. I liked the flow of the book so much I’ve used it to put together a presentation on ASP.NET for our team.

A couple of points I wish would be better:

- The book has no description of ASP.NET Web Services – the only major topic omitted.

- There’s a few graphics in the book that suppose to illustrate processing sequences. The layout of those graphics could have been done better and didn’t really clarify the text they were trying to illustrate.

- The chapter on configuration spends a lot of its text describing how to work with .config files. This topic isn’t really specific to ASP.NET and could have been shortened.

- The author gives valuable recommendations on design choices, but most of the advice is directed towards an Internet web application developers. I wish the author would give more consideration to options relevant to Intranet developers.

Overall: highly recommended for experienced developers.

Mon, 17 Mar 2003 22:07:39 GMT

John Robbins' .NET Developer book 'Debugging Applications for Microsoft .NET and Microsoft Windows' comes out soon. This is one of those books that pays for itself after it solves a bug or two - a very high ROI. Can't wait to get my hands on this one. [SBC]

Got mine at amazon.ca. Review to follow.

Mon, 03 Mar 2003 14:04:26 GMT

Building web solutions with ASP.NET and ADO.NET by Dino Esposito is the second book on ASP.NET I got in past few weeks. (The first one was “Programming ASP.NET” by Jessie Liberty and Dan Hurwitz.) It is advertised as “code-intensive solution-oriented book”, but I would characterize this book more like code-intensive DataGrid-oriented. The book presents only some parts of the ASP.NET and ADO.NET along with practical advise.

Dino’s book does a great job in explaining DataGrid control; gives a good overview of concurrency issues in ASP.NET applications and data provider architecture. A more appropriate title for such book would be “Elements of data-driven ASP.NET applications”.

The author doesn’t waste ink explaining basics of ASP.NET technology and jumps right into introducing data binding on various web controls. By the end of the first chapter it becomes clear that DataGrid Web Control is emerging as a lead character of this book. Chapters 2, 3 and 4 are dedicated to explaining data binding and control features of DataGrid. Then comes Chapter 5 that presents various options of organizing the code and layout in an ASP.NET application. I found this chapter useful, but inappropriate within the flow of the book. The discussion about physical design of ASP.NET application should really be independent from the discussion of DataGrid web control. I felt this chapter was even more out of place when I’ve realized that Chapter 6 continues to cover DataGrid in further detail.

In Chapter 7 the discussion moved away from DataGrid once again and focused on analysis of design choices in dealing various scenarios with disconnected web applications. In this chapter the author shown various techniques of data caching and updating the database in multi-user scenarios. I found this chapter very useful.

Chapter 8 might be interesting for people who have to deal with legacy ADO code within an ASP.NET application. This is not my case, so I’ve skipped the chapter altogether. An appendix would have been a better place for this material.

I’ve only glanced though Chapter 9 to realize that it contains pretty basic overview of web services; its high-level design and its usage with VS.NET. I don’t understand why the author has decided to include this chapter in the book. It didn’t seem to contain any “solutions”.

Chapter 10 explained the architecture of .NET data provider and guided the reader though a fairly complete example of creating a data provider for file system directory listings. Based on this chapter I would not be able to go ahead and write your own data provided for a commercial database. The key take away point from this chapter is that data provider shall be written not only by commercial DB vendors. Anyone who has data in a proprietary store may benefit from creating its own .NET data provider. The discussion lead me to ask the question when it is appropriate to create a data provider. This chapter had little to do with ASP.NET, but is a great complement to the material found in Pragmatic ADO.NET.

To summarize: Buy this book and read chapters 1, 2, 3, 4 and 6 of this book if what you’re looking for is a practical guide on DataGrid control.

Read Chapter 7 before deciding on the concurrency model. Read Chapter 10 right after you read “Pragmatic ADO.NET” to better understand .NET Data Providers.

Mon, 24 Feb 2003 13:49:19 GMT

Pragmatic ADO.NET

Most technical books use fairly limited vocabulary in their titles. The title of the book usually has an adjective (Advanced, Essential, Professional) and a name of some technology. Experienced reader come to expect certain level of content based on the book’s title. When I’ve picked “Pragmatic ADO.NET” as my first ADO.NET book, I’ve relied mostly on the fact that it was written by Shawn Wildermuth (had good Amazon reviews, published in AW .NET Dev Series and endorsed by Chris Sells). I wasn’t sure what to expect from that “pragmatic” adjective. Now that I’ve read the book I wish other authors would consider sharing their expertise by writing “Pragmatic” books.

As any sophisticated technology, ADO.NET offers many options to get the job done. Shawn shows which options are the most practical based on his extensive experience. Shawn’s book doesn’t teach you basics of .NET. It doesn’t teach you internals of ADO.NET or SQL syntax. Shawn refers the reader to other excellent books for details. What “Pragmatic ADO.NET” does well is to teach you about what’s important in ADO.NET from practical standpoint. One of the last chapters of the book includes a great list of “best practices” that summarize the recommendations explained though out the text. Very valuable.

“Pragmatic ADO.NET” is a quick read for someone who has the background with .NET and general idea of database programming. The book will not make you an expert in ADO.NET so if you’re looking for in-depth information this book isn’t for you. After finishing this book, expect to be referring to MSDN documentation and sample code when you work on your data access layer. But you’ll know exactly what details you’ll need to explore further and what parts you can safely ignore.

A few “to-improve” comments: 1) The book has too much long code listings for my taste. 2) Sometimes I felt I needed a bit more information about the reasons why Shawn recommends a particular solution or a best practice.

Fri, 17 Jan 2003 13:22:41 GMT

Advanced .NET Remoting by Ingo Rammer

Essential .NET: The Common Language Runtime

Fri, 17 Jan 2003 13:05:59 GMT

Essential .NET: The Common Language Runtime, by Don Box, with Chris Sells

Sat, 09 Nov 2002 21:32:37 GMT

I remember the time when I decided to teach myself C# - I took a week off and dedicated it to reading and playing with C# and .NET. I’ve used this book for my own 5-day C#/.NET crash-course. Printed a year ago, it was one of the few C# books in my local bookstore. Being pretty experienced with C++ and knowing Java, I feel this book did pretty good job to allow me to get by with C#, but not more. About quarter of this book is about C# while the rest of the book covers various parts of .NET.

This book gives an OK coverage of C# and light overview of .NET. Don’t expect to become .NET expert after reading this book, but it is generally good first .NET book for an experienced developer. Almost certainly you will find yourself needing in-depth books as you continue learning.

The second edition is now available.

Fri, 25 Oct 2002 14:47:02 GMT

High-Tech Ventures by Gordon Bell

After 11 years this book remains a great resource for everyone who evaluates a starup's health or is thinking about starting a business. The book contains a very comprehensive set of really good questions that evaluate the business in every dimention critical to its success. The success is assured if you have the right answers to all of the test questions presented in the book. Great resource for high-tech enterpreneurs, VCs, hires.

Word of caution though. This book isn't really about how to build a successfull business. It's more about how to tell if a given business (or a business decision) is to be successful. Most of the case studies in the book are really annotated examples of falures, as oppose to examples to follow

Highly recommended.

Tue, 22 Oct 2002 14:03:59 GMT

High Tech Start Up: The Complete Handbook for Creating Successful New High Tech Companies
by John L. Nesheim

This book is for anyone thinking about starting a high-tech business and is hoping to finance it. The author does a great job exposing all the complexities of finding the money and closing the financing. This book shows the problems to be watched for at every step of the way. But notice one thing - this book was written that time of common VC and high-tech lunacy. Now when first-to-market-wins rules of the game are no longer applicable. I wonder how the author would change the tone of the book if it was written in 2002.

Regardless of the times, this book shows just how hard it is to get the money and why the financing should be done only if absolutely necessary.

While this book does a great job covering all-things-money, it is not a complete handbook of creating companies. This book does not cover all of the other aspects CEOs need to worry about. If you're looking for a comprehensive handbook, check out book by Gordon Bell.