Software Development Lifecycle (SDLC) (RSS)

Getting Ready For The PASS Summit!

The PASS Summit is less than two weeks away!

I'm getting ready for my presentations. I need a couple laptops to host virtual servers for the demos, so I bought some new gear to take with me.

Check out my Network-In-A-Bag!

Network in a bag!

It's a power strip, a couple CAT6 cables, power supply, and a NetGear 1G 5-port switch - all in a 1 gallon Ziploc bag.

:{> Andy

Technorati Tags: PASS Summit 2007 Networking

Testing With VSTS Sample Chapter Available



The cool people at Wiley (Wrox) allowed the cool people at Solid Quality Mentors to post my chapter, Testing The Database, from the upcoming Wrox release !

:{> Andy

Technorati Tags: Team Edition for Database Professionals Database Testing Unit Testing Wrox Solid Quality Mentors Wiley

Bad IT Project Management

My sister-in-law recently passed the PMP certification (congratulations Heather!). I'm waiting for a call from her asking if we need to add resources.


The resources comment above is a joke, but it isn't really that funny. It's indicative of my decades of experience with bad IT project managers.

I believe and hope I have worked with some of the worst project managers on the planet. Why do I hope? I'd hate to think anyone has had to deal with folks worse than the poor project managers I've dealt with.

As I type, we're experiencing a heat wave in Farmville, Virginia. It was 107 degrees Fahrenheit here yesterday. It's the "dog days of summer", as my Granny used to call them.

Somehwere, you will find 30 or more push mowers lined up wheel-to-wheel along one axis of a lawn. On command, the 30+ operators will start their mowers. On cue, they will push them across the lawn, maintaining the wheel-to-wheel alignment, cutting the entire area in one pass.

This, my friend, is the home of an IT project manager.


My experiences have led me to a couple thoughts:

  • Frederick Brook's should be required reading for all project managers.
  • Proof of callouses should be required for the application process.

(The same can be said for MBAs, but that's for another post...)

Inspired by the book, Brook's Law states "Adding manpower to a late software project makes it later." It is perhaps best summed up by the following statement by Brooks himself: "The bearing of a child takes nine months, no matter how many women are assigned."

As an IT professional, you can learn to detect when you're about to be "managed". I share the following indicators and advice from my years of experience:

"Do we need to add more resources?" This question in and of itself is harmless. It's actually the way project managers greet each other and has no more meaning to ordinary folk than "How are you doing today?" or "How about this weather?"

The best answer to this question is a non-answer. After years of trying to correctly answer this (as though it were a meaningful question), I stumbled across an answer that works for me: "I don't know." Why does this work so well? The last thing a bad IT project manager wants to do is make a decision - at least one traceable to them.

"I am (or used-to-be) a software developer." If you hear this, you're in trouble. Big, big trouble. My advice to you is to vacate the project - and the premises - as quickly as possible. This isn't a fire evacuation, it's a bomb evacuation. You may wish to consider jumping out a window if you're on or below the third floor.

Why? You are dealing with a person who believes they were promoted because they were such a good developer. Mind you, this is true in less than 25% of my experience. And even then, odds are their resume includes COBOL or they aren't nearly the project manager they believe themselves to be. At best you have 1/3rd of a 25% chance that you're working for someone who knows a definition for delegate - a definition that isn't "someone who attends a convention."

The truth of the matter is this person was likely promoted before they could delay or otherwise further damage the software project to which they were assigned.

"What do I tell my boss (or the stakeholders)?" This question is the prelude to a demand. Your answer isn't important, the demand in the mind of the IT project manager is important. And that demand is for you to do something no sane developer would ever do.

There are a couple options. If you're feeling froggy, you can document the fact you were asked to take this ridiculous course of action by your IT project manager, and then do it. Be sure to address the issue in writing and as soon as possible. CC someone else - anyone else. If you can CC the project managers' boss without looking like you're trying to make them look stupid, that's best. If not, CC someone else at your level on the development team (and allow the bad IT project manager to continue their work of making themselves look stupid unassisted).

Note: Never BCC. BCC'ing the boss is the equivalent of placing a bold, red, flashing banner across the top of your message which states "I'M INSECURE". The boss will get this message, loud and clear. Go ahead and CC them if you believe it's warranted - those dogs need to wake up eventually.

Make sure it's in writing and someone else sees it - that's the point.

The other option is to simply ignore it and do what you know to be right and good. There's risk here too. Some bad IT project managers will call in bigger dogs to shout you down. It's good to have your mugshot and name on a book somewhere if you're going to exercise this option.

"Umm yeah. I'm going to need you to come in Saturday. Sunday's not looking good either..." People are people. Bad IT project managers don't get that. They call people "resources". People aren't resources, we use resources, but we're separate and distinct from resources. People are people.


Bad IT project managers are the reason we have IT Project Leads. After all, someone who knows what they're talking about needs to have some authority if any software project is to stand a chance of succeeding.

:{> Andy

PS - This post inspired a new category at Applied Team System: Expensive Management Practices - gotta love the acronym. :{>

Technorati Tags: Project Management IT Software Development

New Book! Professional Software Testing with Visual Studio 2005 Team System: Tools for Software Developers and Test Engineers

is now available for pre-order at !

I was honored to work on this book with three testing gurus: Tom Arnold, Mike Frost, and Dominic Hopton.

The book covers many aspects of testing. More than just what to test, why to test is also covered. Although the book covers testing with Visual Studio, non-Microsoft technologies are referenced.

The book is written for developers practicing test-driven and test-first methodologies, and for test engineers. It provides great insight into the Visual Studio testing framework.

I got to write a chapter on Testing the Database. I use Team Edition for Database Professionals in the chapter to build a database project, then test it. I'm really happy with the chapter. The last section contains a detailed, step-by-step walk-through of building a custom test condition in C#, then integrating it into the TEDP test conditions. I wrote it assuming no experience with the Visual Studio 2005 IDE and little or no experience with software application development. I wrote it so database professionals with no exposure to application development could write their own custom test condition.

The book should be available in September!

:{> Andy

Technorati Tags:

Iteration = Maturity

Introduction 

I was recently reminded that iteration matures software.

The History of Andy, Part 1 

Like many DBAs, I was a software developer in another life. I built web applications - working my way up from HTML through DHTML and finally to ASP - and could regale (and bore) you young whipper-snappers with war-stories of how things were "back in my day". [/DanaCarvey]

But I won't.

The Times They Are a-Changin'

I'll share instead something I've witnessed many times since starting with software in 1975 - and something you probably already know: stuff changes.

And thank goodness stuff changes!

I recently ordered 1G of RAM from an online retailer. It should arrive before my next son (but that's not a given as Riley refuses to provide a tracking number - the doctors will induce Christy into labor Friday if he hasn't been born by then - but I digress...). I remember my neighbor John, who introduced me to computers, purchased a 256-byte RAM chip in the mid-1970s for about what I paid for the 1G. That's 256 bytes of RAM - not a typo. As I recall it was either a 14- or 16-pin IC.

Things have changed since then. Improvements in technology, brought about by building and improving upon existing knowledge, have brought us to a day when I can purchase 1,073,741,824 bytes for roughly the previous price of 256. I don't know how you feel about that. I think it's a good thing.

The idea of "building and improving upon existing knowledge" defines iterative development. Although the idea is relatively new to the software development field, it serves as the basis for engineering disciplines. Engineers iterate - build and improve upon existing knowledge - and we get more powerful hardware for the same amount of money. What's not to like?

Iteration - it's not just a good idea... 

Iterative software development builds and improves upon existing knowledge within a specific domain. Most domains are defined by an application (wholly or in part), enterprise knowledge (again, wholly or in part), or - most likely - some combination of the two. For example, let's say you work for a large corporation as a software developer. Your domain could be the corporate website. In which case you possess knowledge about the business of the corporation and web development. You mix these together to do your job. In this case, you will probably pick up marketing savvy and current trends along with the latest AJAX techniques.

As you make successive passes (iterations) through the website design interacting with marketing, your domain knowledge is built and improves. As your domain knowledge increases, the website will become more valuable to the corporation - as will you.

Iteration adds value.

Got Iteration?

The same can be said for database development.

Perhaps you've experienced this in your own database development efforts: you receive a request for a database design to meet some desired functionality. Or you're handed a design and asked to optimize it. Or maybe even you had an idea to capture data - performance metrics or something similar - and you're designing a database solution to accomplish this.

You get into the development a few hours or a few days and realize a little tweak here or there would improve performance, or readibility, or better adapt the design to your intentions. So you make the tweak and continue.

This improvement leads you to re-examine other portions of the design and you make more tweaks. Maybe your last change broke things. Maybe you see an opportunity to add a parameter to a stored procedure and combine the business logic of three stored procedures into one.

A "Growing" Solution 

Pretty soon, you have iterated enough to feel comfortable promoting, integrating, or even releasing the results - letting the effort move to the next step.

Depending on the nature of your efforts, it may not end there. If your database development is the back end of a larger application - say, the corporate website, for example - there will likely be requests for changes over time as the site grows (scales) in complexity and size.

When the requests come in you are not likely to start over. You will most likely build and improve upon your existing knowledge. You will most likely iterate.

Scaling forces iteration.

Voilà

This is how solutions mature - be they applications, databases, or both - regardless of who writes them or how many are involved in the development effort. It doesn't matter if the development team is one lady in a cubicle in the European Union or a development team of thousands at Microsoft.

Iteration matures software.

:{> Andy

Free Diff/Merge Tool

SourceGear has released a snappy new diff / merge tool - and it's free!

More information is available at Eric Sink's blog - it's definitely worth a look!

:{> Andy

Technorati Tags: Free Diff Merge SourceGear Eric Sink