Peopleware: Productive Projects and Teams (3rd Edition) Book Review

The main goal of this review is to highlight parts of the book and provide a personal experience that relates to them. This entire book is made of real world scenarios, but I will only be able to hit a few in a review. I have had the opportunity to be on many different types of projects during my career. I have been on a project where it was just me and a steering committee, projects that involved several teams around the world, and on teams ranging from 1 other developer to over 30. The one common thread through all these projects is that the highest risk was the people on the project. With the rapid speed at which technology is changing I have found only one way to ensure it works as advertised, Proof of Concepts. The same holds true of my development teams when I have no history with them. With the rapidly changing skill sets out there today, there is only one way to ensure your team has what it takes, Proof of Concept (POC) them. Proof of Concepts (POC) plays an important role in not only testing your choice of technology and architecture, but of your development team as well. There is no doubt that people are nowhere close to being as predictable as software components. Software components are lucky; they don’t have emotions or free will. It is however fairly easy to read a person’s skill levels when what they are making has a predictable outcome. One of my projects were I POC'd my team we were using the Composite UI Application Block (CAB) from Microsoft’s pattern & practices group. I had 3 developers on the team. Each was given an equal workload which included building a complete smart client module from the UI to the DB. The technology proof of concept had already been done at this point, so I knew the technology worked as advertise. The first iteration of development was a POC of the development team and of the framework’s architecture. We learned within a week that the team members had very different levels of ability. One of them was able to code all the layers of the application including the DB level, but didn’t like UI work. One was only able to develop the UI forms, and was able to lay them out well. The other was dangerous in a team environment and was locked out of source safe. The dangerous developer worked on the Help documentation, configuring servers, and did a lot of testing. The initial plan was completely scrapped, which was to have them build complete smart client modules from the UI to the DB, and the new assignments were made. We hit every estimate. If we had not POC’d the development team, we would have delivered buggy late code with each iteration. The point is that no matter how well you architect a solution, or think you have a bullet proof software development process in place, people can unravel your project every time if you don't know how to manage them and their environment. To be able to effectively manage them you must understand the skill set they are bringing to the project. This book can help you do that and much more. I have listed the parts below, but have not included the chapters because many of the titles don't make sense until you read the chapter. Part I: Managing the Human Resource Part II: The Office Environment Part III: The Right People Part IV: Growing Productive Teams Part V: Fertile Soil Part VI: It’s Supposed to Be Fun to Work Here This book not only helps you manage and work with others, it also offers a lot of advice that helps balance work and home life. It shines light on the workaholic and how everyone has a bout of it now and then. One of my favorite topics is undertime. Management thinks they are getting away with overtime, but the balanced (not a workaholic) always puts in as much undertime as they do overtime. One of my mantras for successfully delivering what your business users need, versus what they think they want, is that you are going to have to lie to them at some point in the process. The lie may just be withholding information, but if you want to deliver a quality product, you're going to have to keep that bit of information from them. They are all too willing to sacrifice quality for quantity or perceived time to market. This book explains why the builders should control quality levels. I agree, and when I can get away with it, I don't ask them if I can control it, I just do. Most of my clients I have worked for have no idea that I do 80% architecture, research, coding proof of concepts, requirements documentation, architectural synthesis, and design, and only spend 20% of my time doing the construction coding. Construction coding builds the modules on the framework I put in place during the 80% activities. If they found out, they would want me to just start coding. If I did that, I would be like most places I have seen that do 20% analysis, 80% coding, and another 30% rework. They are always over budget and never meet their fictional timelines. I hate documentation, but it makes me present the project in a form that elicits the problems I would run into coding before I am into deep to make architectural changes. I did have one client find out. He literally sent me an email that had the subject line of "I am paying you to code not think". A year or so after we successfully delivered on time and within budget and rolled off the project, I found out he was called into the board of his organization and was fired for incompetency and hiding the ramifications of his poor decisions from the board. Like I said above, this book does an excellent job of explaining why the quality level of a product should be left up to the builder. I also like the idea the book mentions about the builder's veto power. I would love to have veto power over marketing and the business owners with respect to releasing a product. All too often I have seen premature releases that are accompanied by a nice long known issues list. The book really covers working environments in great detail. Since I left the electronic engineering field I have not had an office with a door except at my home office. I have sat at tables where all the printers were for the office. The printing noise wasn't bad, but the people standing around talking, waiting for the slow printers, was a problem. At work I am in a cube that is noisy 25% to 75% of a given day. I share it with one of the main application support guys on our team, and he often has a line waiting to see him. While they wait I am an open target for them to kill the wait time talking to me. To help a little bit I turn off my phone's ringer. Company policy is to always answer your phone, but 90% of the calls I get are salesmen calling about a product I needed to research. Another thing about the office is they keep it hot in the winter and hot in the summer. They keep it around 76-78F, but I have seen the temperature at a screaming 82F. I have to keep a fan blowing on me and by the end of every week my eyes are wind burnt and bloodshot. My chair I have at work has me going to the chiropractor. They were going to buy us new chairs, but discovered they were too expensive, and we aren't allowed to bring our own chair in. I work from home on Mondays. My home desk provides me twice the area I have at work. I have the room at a cool 68F. I have a great ergonomic chair. If I get a call I can put it on speaker phone, instead of having to hold it to my ear with my shoulder. Context switching is always a big problem. The book refers to it as no-flow time. The book calls the state of being in deep thought and cranking through code or documentation 'Flow'. On average I would estimate I get 20 - 80% more work done on Mondays than any other day of the week because I have the isolated environment I need to think. To get hold of me people IM, email, or call if needed, but I can queue them until I am done with what I am working on. At the office if you don't answer right away they come to your cube and interrupt your thoughts. I was once on a team that hired a tech writer that could not write technical documents. He could not even proof ours which was his main assignment. He would replace technical terms with terms he thought should be there and it would completely destroy the document. He soon had no work to do. This was a government team so they were not going to replace him anytime soon. He started filling his day by popping into our team's cubes and just started talking. By the end of the first week of that I took him into a room and used the white board to draw the architecture I was working on. I numbered the locations of changes that needed to be changed for a user interface change and data that accompanied that change. There were about 6 or 7 places. I described what was happening in each place, and that all those places were being thought of at the same time. I told him every time he comes into our cubes to just talk, he erases everything we had queued up in our brains to make the changes. I explained that we had to take anywhere from 15 minutes to 45 minutes, depending on the complexity of the change to get back to work. He understood and stopped making rounds to our cubes. The very next team meeting our manager said he wants to see more collaboration and he wants us to be visiting each other in our cubes more often to make that happen. The tech writer and I just busted out laughing. I then had to explain the same thing to the manager. Luckily he got it too. Like I said at the beginning of this review, my main goal of was to highlight parts of the book and provide a personal experience that relates to them. I could continue that, and probably have my own book by the time I was done, but I will stop here. Everything in this book touches on the real world experiences we have as software architects, project managers, developers, CTOs, and CIOs. If you are an IT manager, this is mandatory reading. If I ever find myself in a position of hiring IT managers, my first and maybe last question will be "Have you read Peopleware?" If you are considering going into the software world, you must read this book first. It will help you have the right expectations of what you will find there. If you are already in the software world, this book will help you understand why things are the way they are and help you to potentially change them.

Peopleware: Productive Projects and Teams (3rd Edition)

Essential Windows Phone 8 Second Edition Book Review

I think this book is a perfect place to start for those new to the Windows Phone 8 application development. The author covers a wide variety of topics at a level deep enough that you understand the topic and its context. A majority of my experience on Microsoft devices was with embedded C++ to develop Windows CE / Pocket PC and Tablet PC. That was years ago. Last year I built some proof of concepts with Windows Phone 7.5 which broke the ice for me moving to the Microsoft Windows Phone 8 platform. The author does a good job of introducing a lot of topics you need to understand in the first two chapters of the book and then starts drilling deeper into those topics and more throughout the rest of the book. In the first two chapters the author introduces phone specifications, designing for touch, hardware buttons, keyboards, sensors, application lifecycle, live tiles, preparing your machine for development, creating a new project, Visual Studio, Xaml, designing with Blend, working with events, debugging in the emulator, debugging with a device, and using touch. Below are the chapters found in the book. 1. Introducing Windows Phone 2. Writing Your First Phone Application 3. XAML Overview 4. Controls 5. Designing for the Phone 6. Developing for the Phone 7. Phone Hardware 8. Phone Integration 9. Databases and Storage 10. Multitasking 11. Services 12. Making Money 13. Enterprise Phone Apps My favorite chapters where Designing for the Phone and Developing for the Phone. They include coverage of the third screen, deciding on an application paradigm, Microsoft Expression Blend basics, phone-specific design, previewing applications, designing with visual studio, implementing the look and feel of the phone, application lifecycle, the phone experience, and localizing your phone application. My biggest gripe about the book is that some of the source code that accompanies it is pretty much worthless. A few of the projects match the books examples, but for the most part it is too aggravating to try to use. That said, the examples in the book are still good, but just mostly snippets. If you understand the context in which they are used, you will have no problems understanding what the author is describing. Another the thing I like about this book is that it is the first that actually builds an example using SQL Server Compact Edition. I know Windows RT doesn't support SQL CE for some unknown reason, so authors of Windows 8 Store app books just tell you SQLite exists, but do not provide an example of how to use it. It baffles me as to Microsoft's reasoning on this topic. There are a wide range of topics covered in this book and the author goes deep enough to give you the knowledge you need to understand it and where it fits into the Windows Phone 8 world. The author's writing style makes this book an easy read. He is clear and concise. The book does not contain filler content. Over all I highly recommend this book to those getting started with Windows Phone 8.

Essential Windows Phone 8 (2nd Edition)

Patterns of Information Management Book Review

There are some books I think every CIO, IT Director, Enterprise Architect, Software Architect, Business Analyst, Developer, and Database Administrator should read. This book is one of them. I have read plenty of books which I consider classics that will not lose their core value over time. They include Patterns of Enterprise Application Architecture, Domain-Driven Design: Tackling Complexity in the Heart of Software, Refactoring: Improving the Design of Existing Code, Patterns of Data Modeling, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Master Data Management and Data Governance, Enterprise Architecture at Work: Modelling, Communication and Analysis, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Design Patterns: Elements of Reusable Object-Oriented Software, Software Architecture in Practice, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, and Documenting Software Architectures: Views and Beyond. This book is now part of that list. This book is not only packed with knowledge it also contains a lot of wisdom. Presenting information is presenting knowledge, knowing what to do with the knowledge is wisdom. This book contains a lot of both. The book begins with a high level look at the case study used and provides an introduction to information management and the challenges it presents. The introduction also outlines the structure of the patterns. Chapter 2 provides a detailed look at the case study which includes 8 different projects. The projects each make use of different information management patterns. The author's did a great job on the case study they used to introduce the patterns. The next 6 chapters break down the patterns into pattern groups. Chapter 9 groups patterns into solutions that are used for projects that improve company's information management. Below are the chapters in the book. I have listed the projects included in the case study under chapter 2, the pattern groups covered under chapters 3 thru 8, and the solutions covered in chapter 9. Chapter 1. Introduction Chapter 2. The MCHS Trading Case Study -Building an information strategy -Creating management reports -Creating a single view of product details -Creating a single view of customer details -Understanding the status of orders -Delivering information quality improvements -Connecting MCHS Trading into a B2B trading partnership -Exploiting predictive analytics Chapter 3. People and Organizations -Information centric organizations -Information users Chapter 4. Information Architecture -Information elements -Information identification -Information provisioning -Information supply chains Chapter 5. Information at Rest -Information services -Information collections -Information entries -Information nodes Chapter 6. Information in Motion -Information requests -Information flows Chapter 7. Information Processing -Information triggers -Information processes Chapter 8. Information Protection -Information reengineering steps -Information guards -Information probes Chapter 9. Solutions for Information Management -Solutions for changing information nodes -Solutions for integrating information nodes -Master Data Management solutions -Big data and warehouses solutions -Business intelligence and analytics solutions -Information protection solutions Appendix 1. Glossary Appendix 2. Summary of MCHS Trading’s Systems Appendix 3. Related Pattern Languages Appendix 4. Bibliography Patterns Index Regular Index The appendices and indexes warrant a mentioning. The glossary contains topics that are given a description, and a list of one or more patterns the topic is related to. The patterns index along with a regular appendix is nice. In my opinion, the best way to read this book is to read through chapters 1 and 2, and as you come across patterns look them up and read through them. There is a lot to take in with a book like this, so it was not a fast read, at least not for me. It will remain by my side to reference for years to come. I really liked that the authors explicitly pointed out the emergent properties projects run into as they move through the project, and how using patterns and industry standards give us the foresight we need to be able to plan for them. The authors provide a really nice download of all the icons used in the book as well as documents that include a IBM Information Governance Model Whitepaper, Patterns of Information Management Summary, Patterns of Information Management-Reference Card by Group, Patterns of Information Management-Reference Card by Pattern, and a PoIM Icons summary. Another thing I want to point out is that although it is published as an IBM press book, it is technology agnostic. This book applies to all technologies. I found the author's experience level and ability to get all this into one book astounding. Their writing style is great, so it is an easy read, which is great, because there is so much knowledge and wisdom to take in, it is not a fast read. All in all, like I said in the beginning of this review, I think every CIO, IT Director, Enterprise Architect, Software Architect, Business Analyst, Developer, and Database Administrator should read this book.

Patterns of Information Management

Learning jQuery: A Hands-on Guide to Building Rich Interactive Web Front Ends Book Review

If you are considering learning jQuery, this is a great place to start. The author starts the book with an introduction that puts jQuery in context and then helps you set up a development environment. Although I think most people reading this book should already be at a level of experience in which they already have a development environment set up, you may want to use the author's suggestion because it is focused on HTML, JavaScript, and CSS. I am using Visual Studio 2012 Ultimate which works fine, but is a heavy install. After the introduction the author jumps right into some examples to show you the jQuery syntax in several different scenarios. If you have not used jQuery at all this chapter gets you familiar with the syntax quickly. Next the author introduces a bunch of basics. The topics include the Web, Web 2.0, XML, JSON, JavaScript's relationship to jQuery, AJAX, XMLHttpRequest, the DOM, CSS, and DHTML. The topics are not covered in detail, the author just makes sure to cover enough information about each to the level we can understand their place in relation to jQuery. Chapter 4 begins the in-depth journey into jQuery that continues for the next six chapters. The book has three more chapters after the ones detailing jQuery on jQuery UI, Plug-Ins, and jQuery Mobile. I have listed all the chapters below. 1. Introduction 2. First Examples with jQuery 3. Basic Knowledge 4. How jQuery Works 5. Selectors and Filters 6. Accessing the Elements of a Web Page 7. Formatting with Style Sheets Under jQuery 8. Event Handling Under jQuery 9. Effects and Animations 10. AJAX 11. jQuery UI 12. Plug-Ins 13. jQuery Mobile Each chapter goes in-depth, yet they also cover a lot of topics. For example the AJAX chapter covers AJAX and XMLHttpRequest (XHR) Basics, Special AJAX Support in jQuery, $.get() and $.post(), Getting and Parsing JSON Data: getJSON() and parseJSON(), Loading a Script Later via AJAX: jQuery.getScript(). The General Variation for Loading Data: load(), Serializing Data, Default Values for AJAX, and AJAX Events and Event Handlers. The author's writing style makes this book a pleasure to read. He is clear and concise. The book does not contain filler content. One thing I really like about the book is the author did a great job of logically ordering the chapters making it a nice cover to cover read, but it will also work well as a reference in the future. It contains a great index which has had everything I have wanted to look up so far. Mentioning a great a index may seem weird, but I have had plenty of bad ones that have actually hurt the book's usability. The code is really well organized. Each chapter gets a folder and each example gets an HTML page, JavaScript file, and CSS if needed. The page and file names include the sample number in the book which makes them really easy to locate. All in all this is a great book for the web developer looking to learn jQuery. I highly recommend it!!!

Learning jQuery: A Hands-on Guide to Building Rich Interactive Web Front Ends