Complete requirements, project schedules and other fairy tales

The words complete requirements will usually get me to at least crack a smart ass grin. Given the company around me I may even belt out ironic laughter.

The term itself is suspect to say the least. To have 'complete' requirements requires the following:

The product owner or vision holder to have a completely defined picture of what he/she wants.

The same person to have a clear understanding of what technology can do to help her/him accomplish said vision.

The same person to have the ability to communicate 100% of this information to a qualified business analyst or product manager type.

The BA/PM type to have absorbed, retained, and understood 100% of the data they have just received.

The BA/PM type to have the angelic written and oral skills to effectively communicate 100% of these requirements to the people who will actually be doing the work.

And finally to have all persons involved agree that these are the requirements and will not change.

See why I think this is a bed time story. The above scenario requires too much of humanity to ever expect what is on paper not to change.

The last company I worked with had a visionary product owner(if not a complete narcissist and manipulator), a great B/A, a great P/M(scrum master actually). A requirements document of over 1000 pages. Hours, Days MONTHS, were spent in meetings interrogating the vision holders to extract these requirements and get them into a form that the dev team could work with.

As with most things, the project started with great intentions and ended with a dead line.

Of the 1000 pages, very little reflects the TRUE state of the system today, just 6 months after launch.

This system's particular issue was that it was so damn big. Hundreds of moving parts, tens of thousands of lines of code. 40 team members, and 2 people(1 really) to specify all the requirements.

Worse yet the project schedule was totally unrealistic. In the end it became a warm bodies approach. Anyone we could teach to program and shove in front of a PC did the work. Needless to say, once in 'support' mode, most of it was redone.

What I am getting to here is two fold. Requirements are very important to get down and try to get agreement from the product owner that they reflect (at least at that moment) what the system should be. The product owner should have to sign to this effect, good god get it in writing.

The team can then estimate based off of those requirements.

If the requirements change, and they WILL, guaranteed, no ifs ands or buts. Then the tasks can be re-estimated and in some cases, the deals renegotiated, time tables adjusted etc. Unless you are one of the 80% of unlucky bastards that will have to eat the change to make a deadline, because the 'system is useless with out this feature and we won't use it'. Etc.

Point being, change happens, change is usually good. To Error is human, to learn from errors and adapt is what makes us good.

Roll with the punches, don't get upset about change. Let the people who get paid to get upset do it. By the time the change requests have gotten to your level, in most cases it has already been through the management wringer, in some cases someone got a foot in their ass, etc. But crap rolls downhill. Look down and you will see it piling at your feet.

Take the change, make sure that it is implemented with the same attentions to quality that makes you a great programmer, and thank your lucky stars you are not one of the 12% of people in this country that is calling for their unemployment benefits next week.

peace.

Grendal.

The most evil phrase in the industry

If you have spent a descent amount of time in the industry, you have no doubt seen a lot of different ways of doing things. Some you agreed with and some you have not.

After a while you have most certainly run into what I consider one of the most evil phrases to be uttered in development and possibly the business world.

When you asked why a person, a product owner, project manager, lead dev, etc why they did or want to do something a particular way, you get the dreaded response, 'well thats the way we always have done it.'

More often then not, when this phrase is uttered, it is the portent of doom, a herald of destruction and despair in the coming days and months that should send cold shivers down your spine and wondering if the corporate network team blocks monster.com at work.

Why you may ask? If you do, you have never been on the business end of this phrase.

Mind you I am not talking about when someone refer's to a group management decision that your were using this API with the product, nor a set of development standards a company implements. If this were so, this precise phrase would not have been used.

When you hear 'well this is the way we have always done it' or close cousins of it, you are in a situation of arrogance and or ignorance. Not sure which is worse. Not only this the person who uttered this is completely uninterested in input on how or why it could be done differently. Either an uncooperative customer is scared to death of changing things for his userbase thus causing an extra support call or two, or the development leadership has gone stagnant and apathetic. Unwilling to educate themselves on a better way either due to fear or arrogance that they know better.

The point is, if the past 20 years have taught us anything, it is that technology changes, FAST. Faster then anyone would have guessed. Imagine, 1990, just 20 years ago, the internet to most people was a quirky software called prodigy and the first versions of AOL. It was cute, you could post on bulletin boards, email was just catching on to the masses. 10 years ago, dial up was still the major mode of internet access. Computers doubled in power almost every six months between 1996 and 2004, and continues to improve in new and even terrifying ways.

Programming, once the exclusive domain of Uber geeks that make the modern programmers of today look dumb, is now generally accessible and to a degree doable by the masses.

There are a lot more people doing what we do, and with that comes ideas, new techniques, things we never thought of before. A lot of it is shit, pure and total. But with this mass, comes the diamonds in the rough, good ideas that have changed the industry forever.

We have the masses now able to even write their own video games with relative ease with the use of the XNA api for windows. It has taken most of the complicated and cryptic programming at the system level almost out of the picture.

My whole point is, in the 21st century, it is our duty as IT Professionals to keep an open mind in every situation. Be willing to entertain an idea by even a junior programmer. Sure it may be the most retarded idea that you have ever heard in you life, like the guy wants to recreate and modernize the ATARI bombshell E.T. Sure you could ignore the guy, even berate him, make him feel like a douche.

But.....

If you take the time and discuss the options with him, use the time as educational for him....who knows, between you two you could come up with the next blockbuster game.

The same is true in business. You business guys, listen to the ideas your IT folks have to offer. You don't have to accept them all, but just because your department lives and dies on manual spreadsheets and always has, doesn't mean that it should.

IT folks, just because you can do silverlight and flash like crazy doesn't mean that it is the best thing for your companies Peoplesoft website.

Listen, talk, learn. Don't be afraid to be wrong. I and almost every other programmer, server jockey, PM or engineer will guarantee you this one simple truth. You will learn more from 10 minutes of fixing a mistake then a month doing the same safe things day in and day out.

People are smarter then they have ever been in history. Innovations are flying at us at an unprecedented rate. The ability to listen, distill and refine those ideas into usable, efficent, elegant technology is what separates a good programmer from a great programmer.

-JP

Going old school in the new school.

So this is kinda a 2.0. An attempt to try this blogging thing again.

I had lost my job back in Early January. After working like someone bought me at auction for well over a year, putting in hours that would make some doctors in their first year of residency baulk, I became rather jaded with programming, computers, and in general the world.

Recently I have started a new position with a health care IT company in the Detroit area. One of this companies central products involve a Content Management System(CMS) that is heavily marketed to hospitals, education centers, medical centers etc.

For those of you who are not aware a CMS is a system that allows the non-programmer administrator of a website to manage their own content on a website.

To a degree this system has various modules that organizations can purchase, request(and pay for) customizations to these modules to suit their various needs.

Coming into the health care world for the first time, and coming from primarily companies that supported the plummeting American automotive industry, I am confronted with a rather unusual concept in business for me. This company has money, it is growing, this time by more then 5 employee's in my mid sized group.

One team of this group (approx 3-4 people) are launching somewhere around 100 new websites in a 12 month period.

The complaints in this company are about layoffs, or suspended bonuses or 401k contributions, but about not having enough time to train all the new people.

It's almost unsettling.

But the thing that has me kinda going geeky is how we have to program. This is a .NET shop, nothing unusual there. But things change ALOT, often on the fly. So the project compilation is setup alot different then I have done in the past.

Frankly it made me realize I have been spoiled.

Things like intellisense, and inline compilation to immeadiatly tell me when I have boned it up have been a crutch to me in my career.

Often now, many of the changes and work I am doing right now involve opening good old fashion notepad, or its big brother and my personal fav, Notepad++ and going to work.

This really requires you know what you are doing, no intellisense, no inline api reference. Nothing to really tell you that you didn't close that div right.

This is the old school. The days of ASP 1.0-2.0. When you better know what you are doing, because you are changing a live site, and better be damn sure what you are doing.

There are opportunities to program with all the toys of the trade when new dev occurs, but this tickles my geek side.

The great thing is, I realized that I am up to the challenge and can roll with the big dogs.

-JP

Introduction

Nothing could be closer to the truth.

The modern business landscape, in an economy that has been beaten nearly to death, requires skills normally reserved for elite military special operation teams. With their ability to adapt and their training on how to do everything with almost nothing in the worst possible environments draws a strong comparison with what the modern IT professional is asked to accomplish for businesses on a daily basis. Better, Stronger, faster, slicker, and best of all cheaper and oh by the way with 10 people less then it would realistically take to do this and in half the time. The pressure is intense, the margin for error, nil.

Your team requires truly epic survival skills, and that is what we will discuss here.

This will be a weekly blog discussing how to survive in the modern IT industry. Everything from finding jobs, to keeping them, from maintaining existing systems, to developing super systems. Difference we will discuss how to do it the 'right way' while still managing to come in on time and on budget.
We will discuss things we can do to save ourselves a lot of pain as professional developers, and make us look like nothing short of miracle workers. We will get into thinking ahead, account for the future while maintaining our project schedule and not killing our Project Managers.

All topics will be touched in all possible ways. We will get into very general topics of 'Good System Design' from Business Analysis all the way through Database design, Code Design, to Quality Assurance, User Acceptance Testing, Deployment procedures, etc.

In other words we will talk EVERYTHING.

My hope is to provide some good, educational, and entertaining topics that spark thought and conversation around the blogs that lead us all to surviving more as IT Professionals.

So who the hell am I to tell you how to do things? No one really, just another rank and file code monkey. Have .NET will travel.

Seriously, My name is Jeffrey Pryciak. I have been in IT for 12 years and held every position from helpdesk support, to server ops, programming and IT management.

Our small programming team has dubbed ourselves 'Rogue Developers'. We are not married to any specific methodology, programming model, language or tool set. We bring what ever is best to the situation to the table, if we don't know it, we learn it. It is an attitude that has allowed us to design some of the coolest applications our company has seen.

Over the last year and a half my professional forays have led me into pretty large project where I have coordinated with at least 30 people, in 7 different business entities in 10 cities on 2 continents. It ended with all the classical roles that one finds in a large project, and It was one of the most technically complex things I have ever had to deal with. We had many successes and many failures both in procedure and technical aspects. Retrospectively thinking about this project is what has inspired me to create this blog.

So stay tuned friends, this is gonna get good. My plan is to publish a good topic early every weekend so that the next week leads to spirited and heated debate.

I appreciate passion and love a good argument. All I ask is that we keep this professional, keep your comments clean and not personal, and lets have a great time.

Peace.

-JP,

P.S. Just to establish my full geek credentials.....

Smolderthorn US
80 Death Knight :)