Rant: Book Development Editors are a dying breed

I used to do a lot of development editing for books.  It was fun work.  You were able to see the impact on the books you were working with.  You could see author’s writing getting better as they started to get used to your comments.  They would quit taking short cuts.  They would begin to view the material from the reader’s point of view.

The job of the development editor in the book process is to “develop” the material.  In other words, the development editor is supposed to make the material better.  Development editors don’t do this by adjusting the placement of the commas or the number of capatilized letters (that’s the copy editor’s role.)  Instead, the development editor looked at the tone, overall flow, depth, and other broader issues.  They focused the author’s attention on these issues so that they could be improved upon.

What I’ve realized from the reading that I’ve been doing lately is that the development editors aren’t doing this today.  It’s likely because they’re too busy with other projects but still the abscense of this assistance for the author is painfully missing from many technical books today.

The book industry is right to be scared of the Internet and the way that we consume information these days, however, they’re not doing themselves any favors by shortcutting the development process in favor of books that are quicker to market.

I read a lot of blogs, articles, and shorter content on the Internet.  However, when I really need to have a thorough understanding of a topic, or I need to make sure that the information is right, I go to a book.  I use them as authoritative voices — however, this is challenging for me when the books have no more thought or organization to them than a typical one of my blog posts.

I wonder if the technical book publishing community will totally collapse before they learn what made Wrox what it was. Ok, before they went bankrupt.  The point is, however, that the brand of Wrox was powerful.  Having the opportunity to work with them (as a technical editor), I can tell you that they crafted their books.  The development editor was very involved.  They had the material run through two technical editors.  Everything was designed to get a quality product — at the center of that effort was the development editor who was managing all of the support that they were providing to the author.

Of course, the days where you could expect that a book won’t wander — that it will follow a clear, intelligible outline are long gone … Some days, I wish I could go back.

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.)


Fundamentals of Performance Testing

I’m in the process of writing an article for on the declining importance of performance testing.  Without getting into the articles primary arguments, I came to a realization that I felt compelled to share.

Most IT professionals have no idea how to approach performance testing.

I mean that both from the sense of they couldn’t do the testing if the needed to and also from the perspective that they don’t truly understand how it works.  The article for is, as most of my articles are, born out of experience.  I’ve noticed that way too many organizations get hung up on performance.  They avoid items which have been identified as non-performant but which make the development process much easier and therefore it costs less.

So in the interest of educating folks, here is a high level summary of what you should know about performance testing, the details will be in the article …

  • Performance Testing – Performance testing is really a set of related evaluations of the system including: responsiveness, throughput, and scalability.
  • Responsiveness – Responsiveness is how quickly the system can complete an individual transaction.  As the throughput of the application goes up responsiveness typically goes down.
  • Throughput – Throughput is the rate at which transactions can be completed.  Typically maximum throughput is the number that organizations are trying to find.
  • Scalability – Scalability is the amount to which various changes to the environment can impact the maximum throughput and to a lesser extent improve responsiveness.  Different changes can result in radically different effects on throughput expecially when the scalability is directly related to a bottleneck.
  • Bottleneck – A bottleneck is a performance constraint in the system which prevents the throughput from increasing.  Typical candidates for bottlenecks are processor performance, available memory, disk performance, and network performance.

I hope this helps.


Article: Choosing Between a User Control or a Web Part for SharePoint

I generally recommend that users don’t write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.

SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From SharePoint’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control. [Website no longer available]

The Tipping Point: How Little Things Can Make a Big Difference

Book Review-The Tipping Point: How Little Things Can Make a Big Difference

If you’ve been reading this blog then you know that I’ve been doing a lot of reading of my own lately, mainly associated with some professional development in the area of reconnecting to basic software development fundamentals that I’m already aware of and some new things as I try to find some new ideas in the various forms of the agile development movement that I can use or try.

The latest book is radically different.  It’s one that was casually mentioned to me by a colleague, Jeff Juday, who was recently awarded Microsoft MVP status.  He mentioned how he thought the program related to the book he had just read, The Tipping Point.

This piqued my interest initially because I’m always curious about how the market works and Jeff promised the book would have some insight.  (He was right.)  Having written (or written part of) 16 books, I know how random sales can be from one title to another.  In fact, when my friends and colleagues approach me about writing a book and ask me if their idea is a good idea, I usually respond with I have no idea.  The market seems to work in mysterious ways.

The Tipping Point is a book about epidemics.  Not so much the negative things as we associate with the word epidemics but rather about things that have a radical growth cycle.

At some point in the book, I wanted to share a passage with everyone I knew.  Some of my mentors, the pastoral staff at the church I attend, my mother, several of my friends, and some of the folks I know at the MVP program at Microsoft.  The truth is that when I finish this blog post many of them will be receiving a link via email to check it out – excluding those I know read my blog regularly and so they’ll see it anyway.

I found the book enthralling as I examined some of the market reactions I had seen.  The birth of the Internet (really the adolescence of the Internet), the growth of cellular phones (which the book discusses), and I even thought about it in terms of SharePoint Portal Server.  (For the record, I would have written this blog post even without a SharePoint tie-in.)

I remember working with the 2001 version of SharePoint Portal Server.  When I’d talk with my peers most of them would be asking me – “Share What?”  There weren’t many people that knew what it was.  Today, when I talk about SharePoint to people I meet – even outside of the industry – I get a surprisingly high awareness rate.  Most don’t know what it does exactly but they know that people think it’s something to watch.  (As a sidebar, most people who do SharePoint work don’t know exactly what it does.)

The interesting thing is looking at this pattern – and others – and evaluating why SharePoint is such a pervasive word in the IT industry and in the minds of small business owners.  It certainly can’t be attributed to the stellar marketing that Microsoft has done for the product.  (Sorry guys.)

Quietly you’ll get some of the marketing folks in the information worker group to admit that there’s a lot of confusion about SharePoint and few places to find good answers.  I’ve had clients pay for us to develop documents that they can use to internally explain the solution – because it’s simply too hard to do without clear documents on what it does and doesn’t do.

SharePoint isn’t successful because of a greater number of people running Microsoft Office.  SharePoint’s popularity can’t be explained by a renewed interest in IT.  It’s an absolute mystery to me as to why it’s become so popular.  (Here’s a challenge – tell me via email why you think it is so popular.  I’d love to hear your perspective.)

The Tipping Point didn’t explain why SharePoint has become so popular but it did give me the clues to look for to identify what happened.  I don’t have the answers but I do at least know some of the questions to ask.  In that way, I think it will be invaluable in the way it allows me to see things more clearly.

The analogy that I’ve come up with to explain it is that it’s like someone with imperfect vision – like myself – putting on glasses for the first time.  It doesn’t make me see or allow me to see for the first time but it does bring more clarity to what I’ve been seeing all along.  The unfortunate thing is that it has also exposed me to how much I still don’t see.

There are some psychological tenants that most people subscribe to – including me.  That I know believe are false.  I’m questioning how much about the way people behave is about their character and how much is about their circumstances.  (In an interesting turn of events, the environment swapping movie Trading Places was on TV last night.)

If you’re the least bit curious about how trends get started and would like to get a little bit better picture of them I highly recommend reading The Tipping Point.


Recognition vs. Recall

Where did I put that again?

One of the things that’s been fairly constant in my life over the last few weeks — that rediscovery stuff is hard, particularly when you try to do it too quickly.  It’s caused me to recognize that there’s information I’ve seen before but I couldn’t recall it on command, nor can I even remember where I saw it again.

It reminded me of some of the instructional design research I did several years ago while I was doing a lot of development editing for books.  I ran across Bloom’s Taxonomy of Educational Objectives, while I can’t say that I agree with every bit of the classification or the revision of the work.  However, it’s interesting because it causes you to think about how we teach and learn in a different way than we most folks think about it.

What caused me to think about it was the difference between recognition and recall.  These are at the bottom most levels of the taxonomy.  The most basic level is recognition.  That means that if someone asked you what it was you couldn’t tell them but if they say it to you — you will recognize that you heard it before.  Taking from my daily life…  My wife asks me to pickup paper plates from the grocery store.  I walk into the store and can’t remember what it was that my wife asked me for.  (I lacked recall.)  However, my friend, who co-manages the store walks up to me and starts offering ideas on what it might be: bread, milk, cheese, etc.  When he hits paper plates I immediately recognize that it what I’m there for.

The trick, for me, is to figure out how to get more of the stuff I read and take in into the recall category and less in the recognition category.  I could be struggling for higher levels, levels that allow me to do things with the information but for now, I’d be happy to hit recall all the time.

Excuse me while I go look for my car keys…

If you’re interested in learning more about how we educate ourselves and others, it’s an interesting read.

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.


An odd little quirk about not installing VB the first time through

One of the things I’m doing right now is evaluating DotNetNuke 4.02 … So I install it in my VPC and It doesn’t show up.  I think about it and realize that I didn’t install Visual Basic when I installed Visual Studio 2005.  Of course, I couldn’t think of any reason why I’d need it.

Sidebar: I’d love to use WSS V3 for this but the site has to be up much sooner than I’ll be able to get a “go live“ license.  I’m investigating several alternatives with an eye to being able to make the change later.

I go back in and install it and then go back to try to find the templates for .NET nuke (starter kits more appropriately).  I still can’t see them.  I learn about the VSI format (think SharePoint CAB deployment packages using ZIP instead of CAB) and the .vscontent files.  Cool stuff… After several reinstallations it is still not showing up.

I take a step back and realize that the only web templates I have showing up are C# web templates.  Doh.  Something must be wrong with the installation.  It thinks that I don’t want to do VB … since DotNetNuke is VB… I can’t see it.

I’m trying a repair now … if that doesn’t work I get to uninstall and reinstall VS.2005 to be able to evaluate DotNetNuke.

[Update: It’s an odd interface quirk… I had to select one of the VS templates to enable the language selection lower in the dialog … I love stuff like this.]


Preparing for SharePoint Advisor Live! Las Vegas April 9th-12th

I’m just sitting down to get some work done on my presentations for SharePoint Advisor Live! in Las Vegas April 9th-12th and thought I should share with everyone the three sessions I’ll be doing…

  • Get your SharePoint Project Started Right : SharePoint projects are often lost in enthusiasm and don’t have the requirements gathering they need to succeed. Learn how to get the requirements you need to have a successful project. Find out about techniques for clarifying terminology and for getting the most out of prototyping. Learn real world tips for recovering from bad requirements. Whether your project has already started and is off track or you’re just getting started and are already concerned, this session will help you be successful. You’ll take home a worksheet that will let you make sure you get all the important requirements for your SharePoint project.
  • Use SharePoint Portal Server Search to Find All of the Information in your Organization : Locked away in the files on your file servers, in your ERP systems, and in your custom written applications is the collective knowledge of the organization. Microsoft SharePoint Portal Server (SPS) can peer into these repositories to collect all of that knowledge and make it accessible to you. Learn how to enable SPS to search all the information in the organization. Learn the details of how SharePoint search works and how to configure it. Learn how to create advanced search criteria in SPS. If you’re struggling with search, then you need to come here to learn how to get control of it.
  • SharePoint Backup and Restore : Critical information goes into SharePoint each day. Recovering that information in the event of a “disaster” is essential. Learn how to back up the information so you can recover it. Learn about the out-of-the-box backup solutions as well as the third party options for backing up your SharePoint data. After you have fundamental backup options, you’ll also learn to create a backup strategy that allows you the most recovery options. You can’t afford to loose your data so you can’t afford to miss this session on the ways to recover from a “disaster.” Take home a solid understanding of the backup options and their benefits and weaknesses.

I’m looking forward to seeing everyone there!


Are you really saving money through off-shoring?

Let me first start out with two process notes…

1) It’s hard to get an article like this published on the Internet because of the substantial amount of web traffic which is coming from off shore.  That’s why this is a blog post.
2) I have the GREATEST respect for many folks who happen to be outside the US.  This isn’t an attack on the idea in general — it’s an open conversation (albeit one sided) about some of the ways that outsourcing costs more and no one can see it.

First, as I’m preparing to push for my new commerce web site ( I’m seriously looking for being as efficient as possible.  That means the review of techniques and thinking that I’ve been doing, but it also means looking at how to acquire the construction resources I need.  (I’ll be doing most of what represents requirements and design myself — in whatever form it takes.)  I’ve found a few different options for getting the construction done — and they look like they’ll be a great way to keep my costs down.  However, I’ve also seen first hand how off-shoring can fail to work.  Here are a few warning signs that I think many organizations miss…

1) The off-shore resources aren’t following coding standards (or you don’t have coding standards).  This just means tons of rework with no hope of any escape.
2) The off-shore team doesn’t receive any training of any kind.  You don’t coach them on how to develop software better.  You figure that they’re contractors and you shouldn’t waste your time on training people who aren’t on your staff.  The fallacy with this idea is that you don’t realize how much cost you’ll incur between the time you identifiy they need the training and the end of YOUR project.
3) You’re noticing a high defect rate.  Of course, you’ld have to actually track defect rates and associate them to the code that caused them (which many organizations fail to do).  If you did you might notice that a disproportionate number of your defects are coming from off-shore.
4) You’re having to define things in such detail that you feel like you’re spending more time specifying the code than it would take to write it (and you’re not getting what you asked for.)  If you can write it faster than it takes you to write the specification… then you might want to just write the code.

Most people ignore the warning signs above because they don’t measure the right things, they’re oblivious, or they simply don’t want to hear it.

Remember that finding a defect late in the process can cost 100 times as much as fixing it quickly.  The fewer repeatable defects you’re fixing the more likely you are to find the important defects that might slip through.

A final note, both traditional plan-based development and agile development work better with better developers.  Agile is particularly sensitive to having good developers.  If you’re not helping your developers become better, you’re shooting yourself in the foot.