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

Article: A High Performance Model for State and Caching

Every Web application has to deal with session state in one way or another. Most default to the state management built into the environment of the language they’re using. It’s simple, quick, and in many cases effective.

The problem comes in when you’re trying to build a high volume site and the standard way of doing things just won’t cut it. Dumping everything into session state just doesn’t work; caching becomes a necessity. You’re forced to start bringing more things into memory per user—while simultaneously keeping your per-user memory utilization down. It is when caching is added to the performance mix that you begin to really see how your fundamental views of session state and caching need to shift.

In this article, I present a model for creating different pools of information tied to both, how the information is used and how expensive that information is to reproduce. I’ll detail a method for improving performance using careful management of state and cache.

http://www.developer.com/tech/article.php/3593386

forge

Article: Generate development documentation with the inclusion by reference method

Whether your software development process is the antique waterfall method or something more razzle-dazzle like the latest agile methodology, you have got to be creating some minimal levels of artifacts like documentation. That is, of course, excepting those who continue to use no methodology, or the methodology of “code and fix.” While much attention has been paid to the excessive weight of artifacts, including documentation, in recent years, little has been done to talk about strategies which still meet the need for a common understanding of the software, while at the same time minimize the effort required to create and maintain documentation.

One technique which deserves some attention is the idea of including documentation by reference. In other words, refer folks to a more comprehensive source for the detailed information while maintaining a reasonable summary in the document itself.

http://www.techrepublic.com/article/generate-development-documentation-with-the-inclusion-by-reference-method/

forge

Article: How SharePoint and SOA Fit Together

What do you get when you take SharePoint, a wildly popular product, and Service Oriented Architecture (SOA), a widely misunderstood but sought after technique for improving the agility of an IT department, and put them into a single article? Hopefully you get a popular article where people poke their heads in to learn if this is another combination like peanut butter and chocolate, or if it’s more akin to spinach and strawberries.

Services Oriented Architecture is a perspective on how to build systems that emphasize reusability, loose coupling, and standards-based approaches. SharePoint is a specific portal technology that is focused on getting information into the hands of the users who need it as quickly and as simply as possible.

In this article, we’ll explore how SOA and SharePoint work together to help organizations that are struggling with minimizing costs and maximizing benefits

http://www.intranetjournal.com/articles/200603/ij_03_16_06a.html

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

Article: Squeeze more out of the construction phase of application development

The world of software development is changing. Software development tools and frameworks are promising to improve speed of development. New agile development techniques are changing how we approach the development process. Whether your organization has adopted new tools, new methodologies, or is just looking at what’s going on in the market, you’ve got to account for the compression of the construction phase of the software development process.

http://www.techrepublic.com/article/squeeze-more-out-of-the-construction-phase-of-application-development/6049011/

forge

Article: The declining importance of performance testing should change your priorities

In this document you’ll learn why the declining importance, and therefore the limited gain, of trying to determine the performance and scalability of systems should reduce the priority you’re placing those activities.

We’ve reached a day when a fast server can handle almost any single load that is thrown at it. For a few thousand dollars, perhaps $5K to pick a round number, you can have a system that will perform adequately to almost any load. Because of this performance testing is becoming a luxury that few can afford.

Of course, there are some organizations that will find that their applications can not be served on a single server or even a small farm of servers. Their tasks will be so large, difficult, or expansive, that no single piece of hardware can solve the need—however, the number of organizations with those needs is dramatically shrinking.

http://www.techrepublic.com/article/the-declining-importance-of-performance-testing-should-change-your-priorities/6044115/

forge

Article: Avoiding Coupling in Your Portal Implementation

Software development has for a long time sought to reduce the amount of coupling between various components of the system. The goal was creating systems where parts could be replaced without requiring massive amounts of rework — or simply replacing the whole system.

Portals, which are necessarily at the heart of an ever-changing array of programs and solutions within the organization are especially vulnerable to coupling. It starts out simple at first: the special notice that one application needs, and before long your portal projects are caught behind the schedule of a dozen other applications — and a dozen different projects are waiting on your portal project to be revised before they can put changes into their products

No matter how careful you are, there will be some coupling to other systems that cannot be avoided. However, taking a stand against allowing your portal to become coupled to other systems can make it easier to continue to update and revise your portal.

http://www.intranetjournal.com/articles/200602/ij_02_22_06a.html

forge

Thoughts on Optimisim and Pessimism

Thomas Edison was once asked about his failures in creating the light bulb and his response is often quoted as “We now know a thousand ways not to build a light bulb.”  That’s a dedication to staying positive that few (if any) of us could muster these days.  It’s a passion for creating the light bulb that would not be discouraged.
Through some of the reading I’ve been doing lately, I’ve been consumed with thoughts about how you perceive the world around you will drive how the world around you becomes.  This probably isn’t true in the literal sense (however, I wouldn’t discount it.)  What is true, however, is that we have two types of people: The optimist, always believing that there is more than their really is – but happy in that thought, and the pessimist, always believing that there is less than there really is – and miserable or fearful in that thought.
The classic is to place a glass with water equal its total capacity and ask if it’s half empty or half full.  The optimist is supposed to answer that the glass is half full while the pessimist answers that it is half empty.  A few severe pessimists, and I know some, would tell me that the glass may only be half empty now but due to evaporation, perhaps a crack in the glass, unidentified forces, etc., they’re sure that the glass will eventually become empty.  (It’s about that time that I reach over and drink it to prove their point.  It’s a fun thing to do.)
So there’s nothing new here.  You already have heard these things.  But what you may not instinctively realize is that optimism is its own reward.  Sure, I have to accept disappointment.  I’ve set the bar higher. I’ve decided to expect that things will go well, that life is ultimately good.  In return, I get to delude myself into a happy state.
And, of course, the “storms” will come, as they always do to try to convince me that the world is an ugly place.  And at those moments, I’m frustrated, disappointed, and worse.  However, that happens so rarely, that I get most of my days filled with happiness.
The mother of one of my friends is a pessimist, the kind that believes in evaporation, she recently shared with her daughter – “See, I was right.” It was in reference to some pessimistic “The sky is falling” prediction.  The answer back was the classic answer from an optimist: “So what, if you always predict something bad will happen – eventually you’ll be right about one of them.”  In other words, the optimist doesn’t have to assume that everything will always go right, they can be realistic about bad things happening, and they just believe that it’s a small proportion of every day life.
Fairly recently we were at a zoo and had our son’s wagon stolen.  We were able to recover it in relatively short order, however, its impact on our son’s small mind was fascinating to watch.  It had never occurred to him that someone would steal.  Why would you take something that wasn’t yours?  This plus trying to figure out both mommy and daddy’s reactions was putting his poor little mind into overdrive.  The end result was we got the wagon back.  He still vividly remembers the incident (perhaps too vividly.)  He has changed his behavior.  He still takes his wagon to the zoo; however, we keep a closer eye on it.  He didn’t give up.  He didn’t refuse to enjoy the zoo just because a bad thing happened – he simply is more aware of the possibility of a bad thing happening and tries to plan for it as best he can.
So my parting thought, a quotable, is simply this:
“Failure is only not trying because there is no hope of success.  Persistence guarantees eventual success through hope.”
Be an optimist, what do you have to lose?
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.