Posts

Web Hacker Boot Camp

Book Review-Web Hacker Boot Camp

“What evil things lurk inside the hearts and minds of men… “

When I was still in high school – many moons ago – I remember a programming competition. We were supposed to create a program that calculated the length of a line in a triangle (or some such trivial problem). To test your application once you said it was done, the judges would often enter a negative number for the length of a line. On a whim we had put a trap in for that particular condition while building the program. It was this test that helped us complete the challenge.

Putting testing into our code today for bad values seems commonplace. We test for values out of range and have validation controls and all sorts of things that lead us toward developing more robust solutions. However, despite all of our advances in the areas of validating user input, we as an industry still struggle with security issues in our applications.

While the news may be focused on the next new exploit of Windows – because that has mass appeal –  we are still finding that our applications have their own flaws in them that can be exploited just as easily as someone exploiting a flaw in Windows. Actually, much of the time the mistakes in our applications are much more trivial to reveal.

Web Hacker Boot Camp is a journey through the mind of a hacker. It reveals how hackers do their job and what their techniques are. It stops short of telling you precisely what to do to make your application secure, but it certainly provides you with the information you need to think about to make the application secure.

There’s good content in this book if you’re interested in how to fortify your application against attack. The only downside is that you’ll have to look past some editing and layout issues to get the information out of the book.

If you want to discover how you could lose control of your web servers because of flaws in your application code, Web Hacker Boot Camp is definitely a book to get.

SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Book Review-SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Whenever a new SharePoint book comes out I’m very hopeful. There is so much to learn about SharePoint. Some of these things are strategic and cultural. Others are the inane details that allow you to make SharePoint do what you want it to do.
I quickly put this book into the details category with the highly specific and technical title. I was not surprised in this way. It drops down right into the details, right away. No stopping to smell roses, or fluffy introduction chapters – “just the facts, ma’am.”
Unfortunately, my read of the book led me to wonder whether it was providing extra value or not. Primarily, I was thinking about these free resources that have a similar level of coverage:

If you prefer a book that provides a lot of information in one place, rather than taking the time to gather it for free, this could be the right book for you.

This isn’t a book that I will generally recommend, but it does a reasonable job of covering the material, even if it does sometimes make leaps of understanding.
The Psychology of Computer Programming

Book Review-The Psychology of Computer Programming

One of the more interesting questions that I get is how to get an organization to adopt agile methods. Sometimes folks frame it in terms of a problem: “I’m trying to get my organization to buy off on agile development, but they’re not convinced.” I believe that the book The Psychology of Computer Programming can really help with making agile development more powerful. Let me explain.
One of the things that I’ve noticed with most of the agile books, articles, postings, and so on, is that they describe WHAT to do and HOW to do it. However, they are noticeably missing the WHY it works. They’ll argue that WHY to do it is that you experience more productivity, efficiency, quality, etc.; however, they rarely attempt to explain WHY those benefits occur.
So how can a book that was written 25 years ago explain how agile works? The answer is simple. Agile works because it capitalizes on the psychology of programming – even if it only capitalizes on it by accident. Penicillin was created by accident, remember. Some of the core reasons why agile practices work are explored with experiments in The Psychology of Computer Programming.
By now you should be asking, “Okay, so how could I use it to help me sell agile to my organization?” The answer has to do with some of the antiquated material in the book and the way that they may seem nostalgic to the managers who are leading the technology department.
The book was originally published in 1971, so its references are, to say the least, a bit dated. The language examples are FORTRAN and PL/1. The most prevalent system mentioned is OS/360. There are references to punched cards and computer rooms. Terminals are just beginning to gain favor. However, despite the quite noticeable and sometimes distracting antiquated references, the core messages about how programmers (developers) work with one another and with the computer are still clear.
Frankly, the references to older systems make the book more credible than the respected agile books of today. Senior technical managers often will remember these systems with a sense of loss that they can no longer develop code. (Everyone’s inner geek suffers when it’s not allowed to grow.) Because of this connection, the more formalized study methods and the slightly academic feel of the writing makes it a book that is believable to anyone who grew up through the technical ranks.
So how do you use this? First, read a copy of The Psychology of Computer Programming, plowing through some of the parts where it seems like there may be little to offer in terms of today’s agile methods. Highlight the sentences and paragraphs that align to today’s agile practices. Then hand it over to the manager who’s not convinced that agile is the way to go and ask him to read it.
You know that they aren’t likely to read it, but they may flip through and notice your highlighting. You’ve got them hooked. If they read around the highlighted passages they’ll find that comfortable nostalgia and, hopefully, settle into trusting the book.
From there, it’s just a matter of hinting that you should try some of the ideas outlined in the book – that just happen to align with one of the agile methods you’re looking at starting.
I have no idea whether the founders of the agile methods that folks are reading today read The Psychology of Computer Programming, but whether they did or not, there are certainly some interesting correlations.
Peopleware: Productive Projects and Teams

Book Review-Peopleware: Productive Projects and Teams, 2ed

I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams.  It wasn’t because the material wasn’t good — it definitely is.  It’s not because I felt squeamish about the title — I didn’t.  However, I did feel like I should have somehow managed to have read it before now.  With the original edition written in 1987 and the 2nd edition written in 1999 — I should have read it before now.  Alas, I hadn’t.

Peopleware is, as the title suggests, about people.  It’s about how people and software development fit together.  It’s not another methodology, it’s not a set of programming tips.  It is, however, some interesting insight on how people work, don’t work, and work together.  It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.

I collected a few quotes that I believe highlight the value of the book:

  • “The major problems of our work are not so much technological as sociological in nature” (p4)
  • “The statistics about reading are particularly discouraging.  The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.” (p12) [Ouch]
  • “People under time pressure don’t work better; they just work faster.” (p18)
  • “Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code.” (p21)
  • “People just don’t work effectively when they’re locked into a no-win situation” (p28)
  • “The manager’s function is not to make people work, but to make it possible for people to work” (p34)
  • “People can keep track of only so many human interactions” (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]

The book read, to me, as the background information one needs to understand why agile methodologies work.  It’s sort of like reading a book about the internal combustion engine when you drive a car to work every day.  You don’t have to know how the car runs, but when you break down on the side of the road it comes in really handy.

If you’ve not managed to make it through this classic work and you work with others as a manager or as a team member — you should.

Professional .NET 2.0 Generics

Book Review-Professional .NET 2.0 Generics

I was trying to post a comment today to check out a book — a book that I had read and thought I had blogged about but apparently I blogged about it in a dream.  (Yea, I know sick)

The book is Professional .NET 2.0 Generics while I can certainly tear apart some of the mechanics of the book, overall it’s a thorough coverage of the topic both from a breadth and from a depth perspective.  I remember learning more about how the CLR works and the impact of a compile time vs. run-time type generation than I thought possible.

If you’ve got more than a passing interest in generics you should check it out.  You never know, you may just become the generics expert at your organization.

Micro ISV: From Vision to Reality

Book Review-Micro-ISV

When I blogged about Software that Sells: A Practical Guide to Developing and Marketing Your Software Project I commented that there wasn’t much information that was in the book that I didn’t already know.  The guide was really very light on details.  Micro-ISV: From Vision to Reality is a very different story.  I found all kinds of things in the book that were interesting.

I rarely “dog ear” a book these days.  I make it a point to have a pad of paper and pen with me when I’m reading a book.  That’s mostly so I can record my thoughts.  Sometimes I’ll stop reading and start frantically scribbling notes.  Anyway, it’s lead to a lot of books that don’t get “dog eared.”  I even have tape flags that I use to mark what page I’m on — thus no “dog earing.”

However, I haven’t even made it through all of the pages I “dog eared” in Micro-ISV.  There seemed to be a new web site or product that I didn’t know about on every page.  Admittedly Micro-ISV will have a relatively short shelf-life in terms of it’s value because web sites change and companiese go out of business.  However, for now, it’s a great reference for those who are struggling to get a product company going.

The other interesting thing about the book is that it has a great number of interviews in it.  Real people with real problems not unlike your own talking about them.  All in all, a good read.  (I suppose it doesn’t hurt that the author is a former reporter.)

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Book Review-The Rational Unified Process Made Easy: A Practioner’s guide to the RUP

It’s very in vogue to describe your software development process as RUP.  Describing the current methodology as agile (XP, Crystal, Scrum, etc.) evokes too many questions, but describing the methodology as Rational Unified Process, more frequently RUP, leads to fewer questions but puts you ahead of those who are still running a waterfall process.  However, in many cases RUP isn’t really the methodology being used, it’s simply renaming some of the processes and artifacts that were done for waterfall with new names.

The beauty of the book The Rational Unified Process made Easy: A Practitioner’s Guide to the RUP is that focuses not on enumerating the artifacts that one might use with RUP but rather focuses on the core concepts, fundamental precepts, and spirit of RUP.  In this way it intentionally steers the reader away from the natural tendency to try to implement every artifact, to create the highest ceremony process possible.  It provides a balanced view on how to utilize RUP to run effective, successful software development projects.

It also contains a role-by-role review of RUP.  This provides a view of the process from each role’s perspective.  The benefit of this is to condense the amount of training that must be done to get everyone working on the same page.  While they can not be considered a direct replacement for training, the chapters are a good start to helping the team member understand what RUP is all about.

Even in a world enamored with agile, RUP still has it’s place.  It’s proven for larger projects, and provides a path to an iterative model — essential to every form of agile development.  If you’re trying to get to agile RUP is a good stopping point along the way — and the book The Rational Unified Process Made Easy is a good way to understand how to do RUP.

Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Book Review-Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Do you know why you don’t see a lot of negative reviews of anything in magazines?  The answer is simple.  Why print something that is negative when you can just as easily print something positive?  Well, the beauty of a blog is that I can post something negative if the item deserves it.  This is one of those cases.

I just finished reading Software That Sells: A Practical Guide to Developing and Marketing Your Software Project.  Actually, there were several sections that I couldn’t force myself to read.

The information contained in the book is trivial, obvious, and sufficiently non-specific so as to be non-actionable.  In other words, this is stuff that nearly everyone knows.  You could buy someone in your area a drink at the local tavern or pub and get a more coherent delivery of useful information.

While I do realize that there are some folks who are very early in their careers who might be able to find value in the broad coverage of topics, most people will find the coverage too trivial.  What is worse, in my opinion, is that the author doesn’t provide the reader good references to go find more information.  There are chapters on marketing and sales, but no references to other books that cover these topics in detail.

So, if you’re trying to figure out how to start a Micro-ISV (small software product company) you may want to keep looking for a good book.  (Micro-ISV by Bob Walsh is on my reading list still.  I’ll let everyone know what I think of it.)

Agile & Iterative Development: A Manager's Guide

Book Review-Agile & Iterative Development: A Manager’s Guide

The latest book to succumb to my ravenous appetite for software development is Agile and Iterative Development: A Manager’s Guide.

More than any of the other books, this book convinced me how astray we’ve all been lead astray by waterfall based development.  While most of my consulting career has been spent adapting waterfall to meet client needs and the needs of the consulting organization, it’s interesting to realize that the fundamental approach to development was wrong.

I particularly liked this books coverage of details.  It talks about how iterative development got started and how current agile practices are linked to iterative development.  It also has great coverage of scrup, xp, up, and evo methodogies — and how they work together well and places where they don’t work together well.

All in all, this is a great guide for people who are open to better understanding what they do well and don’t do well in their software development.