If you ever had to convince a client or a boss why Agile works, you know that it's not an easy task. Agile goes against many ideas that are considered axioms in the business world - like planning first and then keeping to that plan: "plan your work, then work your plan". If that is the case, these points from a talk by Martin Fowler and Neal Ford (ThoughtWorks) might help you.

In the Plan Driven approach, a project is successful if it goes according to plan, so in software development it depends on requirements stability, on having clear and fixed requirements. As you probably know, that is a luxury most software projects don't have, and a first approach would be to apply techniques like Change Management or Sign In Blood to contain the changes. Unfortunately that leads to unhappy clients and unusable software.

The Agile approach is to break the dependency on requirements stability and come up with a process that takes into account changes. It does that by using Adaptive Planning and Evolutionary Design.

Adaptive planning implies going through the project cycle many times, re-planning and re-adapting often.

Evolutionary design can be achieved with the help of practices like Self Testing Code, Continuous Integration, Refactoring and Simple Design.

If this made you curious, I highly recommend that you view the complete talk here:

Note: this article is about software development jobs, but most of the points made apply to any kind of job out there.

Are you annoyed that, despite your many years in the company, you still didn't get a promotion? Or even a raise?
Even worse, the company is hiring people to cover upper level openings instead of promoting you?
Do you have a boss that is 5 or more years younger than you?
Or have you been interviewed by someone that is 5 or more years younger than you?
Are you afraid that you'll have a hard time finding another job, should something happen and "separate" you from the current one?

Think about it, and don't fool yourself... If most of the above applies to you, it's ALL YOUR FAULT!

So if you think about complaining that the company you work for doesn't appreciate your true value, or that there are no jobs because of the crisis, you ARE fooling yourself.

Still not convinced? Let me ask you this:
How many books did you read last year? And I'm not asking if you read the latest Harry Potter, I'm talking about programming books, software development books. Oh, and the "red Microsoft books for certification" don't count either. Most "Microsoft Certified Application Developers" I’ve seen couldn't figure out the syntax for a property.
What new technologies have you learned in the last year? (i.e. Can you really take advantage of .NET Framework 3.5 or are you still stuck in 2.0?)
Have you learned any methodologies or programming techniques? Agile and TDD have been trendy for some time now... do you REALLY know what they are about?
How much of what you learned this year can you really take with you to the next job? It's nice that you are now an expert in using Excel as a database because that's what your current job was about, but that won't help you much in getting a job working with MS SQL 2008.
Try this Programmer Competency Matrix. Find out where you’re lagging behind.

You can stop reading now if you (still) think your career is on a good path.

Still here? Good :)
So, what do you need to do? Increase your VALUE, of course.
You could see your VALUE as what the market is prepared to pay for your knowledge and skills.

Knowledge

General - languages, methodologies, patterns & practices, software architecture, etc.
The advantage of learning a new language, for example, is that you'll be able to use that knowledge for another job, in another company. You should try to direct yourself towards really valuable knowledge - learning Visual Basic 6 will probably help you less than learning Visual Basic .NET or C#.
Domain specific - accounting, vector graphics, banking, specialized programming languages, etc.
Getting this type of knowledge can imply a greater effort and will increase your value only when dealing with companies from that specific field. So think twice before spending 6 months learning about tombs and tombstone designs.

Skills

Ex: coaching, communication, team work, leadership.

Don't expect to be put in a management position to learn about leadership. You have to show yourself as the natural choice for the job before getting it - don't expect the company to just "give you a chance" and see how it turns out. Leadership does not equal official authority. Being able to work well with the team and help get the best out of your team mates will make you more valuable than being able to code alone like crazy for hours.

Now, your VALUE is what you sell when you go to an interview or when you ask for a pay raise. If it hasn't increased, you won't have any leverage in the negotiations.

The faster you raise you value, the better. Why? Because your time is limited!
There comes a point when your age starts to work against you. Are you 35 and you only have experience in VB6? Why should someone pay you more than a 23 years old with basic knowledge of C#? It's even worse: the 23 years old might have a thirst for learning new things, but you've certainly proved that you don't.
Basically, if you increase you value slowly, there could come a time when your pay will freeze, or start to decrease, or, even worse, you won't be able to find a job.
If you raise it fast, you can get to a point where you are in upper management or you have your own business - not so many worries for the years to come. And whatever happens, you'll have your value to "sell" to the highest bidder.

Is my value rising? How fast? Is my income rising? How fast?

Ask yourself these questions. Is your value stagnant? Work on it! Your value is up and your income didn't catch up? Get a raise, or get a better paying job!
You might be able to get a better income once or twice by using your negotiating skills, even though your value is not (yet) worth it. Don’t count on it though – in the long run, the sure way to do it is to raise your value.

So keep raising it, unless you want to end up with someone young enough to be your son to humiliate you in an interview!

I stumbled upon this Programmer Competency Matrix.

It is an interesting exercise to check your level and to identify weak areas that you can develop.

Oh, and try not to fool yourself while doing it!

I used the word "help" in this post ( We can’t use Test Driven Development! ) because TDD is not a silver bullet. NOTHING is. But that is not a reason not to look for improvements in the way we work.

I'm going to try to explain why I think TDD can help you in MOST of the software development projects out there.

First, mentioning something like "zero defects guarantee" when talking about TDD or testing in general is a hint in my oppinion that a lot of people see the tests as a way to FIND defects.

Myth: The Job of Testing Is to Find Defects

The job of tests, and the people that develop and runs tests, is to PREVENT defects, not to FIND them.

(Mary & Tom Poppendieck, "Implementing Lean Software Development From Concept to Cash")

Knowing that, correct me if I'm wrong with this train of thought (and see if it applies to your case, I can't think of a project where it would not apply):

1. To have or not to have tests. (By tests at this point I mean test cases, automatic or manual, covering the whole system or just a method. Tests in general).

Not having tests leaves me with the task of guessing whether my functionality really does what it is supposed to. Remember, computers do what you tell them to do, not what you want them to do. So having to tests would mean code -> compile-> mark task as done. Unfortunately it actually happens, and way too often.

But that's not the way we do it! The developer DOES check that it works!

Ah! That IS testing, so we MUST have tests then!

2. To have a test list or not.

Testing the software by randomly executing operations will not give you enough certainty that it does all it is supposed to do. The reasonable thing to do is make a list of tests that cover all the cases you can think of. Of course, the list is not cast in concrete - tests can be added or modified.

The list can be an excel or word document. Or code. Or a table on a whiteboard. Or a scribble on a piece of paper. Keep it in your memory only if you never forget anything (hello there, R2D2!).

The important thing is that it needs to specify the setup, execution and validation for each test so it can be shared among team members.

3. Define the tests before or after implementation.

Both work, but tests defined them after implementation (especially by the developer), will tend to validate what the code DOES, instead of what it is SUPPOSED to do. More, defining the tests before can help the developer contemplate cases he could have overlooked and serve him as a progress indicator (9 out of 10 tests passing is a hint that you are close to finishing).

4. Automated or manual tests.

Being able to run your tests automatically and have the feedback in seconds instead of minutes is, of course, a big plus. And, you can setup a Continuous Integration server to give you fast feedback about integration problems.

You have to take into account the time to implement them though. And testing whole applications can could imply slow operations like setting up data in databases or connecting to services. And, depending on your frontend technology, you might find that UI testing frameworks are still limited. Which brings us to the next point:

5. Big coverage or small coverage tests.

Small coverage implies cheaper tests - cheap to develop because you can mock external dependencies and check a specific flow without worrying about "downstream" effects, and cheap (fast) to run because everything is in memory - no database access or web service calls. This type of tests are usually called UNIT TESTS.

Having a good coverage of the internal workings of your components allows the bigger tests to cover the integration parts, the communication between them, validating that they play well together.

In conclusion, if the above applies to you (and if not, I welcome comments on why it doesn't): you should ALWAYS HAVE TESTS, DOCUMENT them, preferably define them BEFORE implementation, and you get a big productivity bonus if they are AUTOMATIC which is a lot cheaper if most of them are UNIT TESTS.

You just have to put some pressure on them! Set a deadline!

After all, it works for programmers, doesn't it?!?

Management is used to negotiate everything, so when the developers come with an estimation for the work to be done their first reaction is:

"2 weeks... That's ok... Now what if we put pressure on them? Tell them they have a week to get the job done."

And I can understand that... It's the job of the development managers or directors to keep things in balance and ensure the developers get the necessary time to do quality work. If not, they WILL cut corners in quality. At 10 PM they WILL choose going home over spending some more extra hours making and running tests.

What I can't understand are the people with a programming background that, as soon as they start climbing the company hierarchy, they start setting out-of-the-blue deadlines for the developers they now manage.

What über programming technique were they using in their programming days when they got unrealistic deadlines to get the job done in time AND with quality?!?

PS: Just to be clear, this article not is about deadlines in general - it is about deadlines set without taking into account the developers' estimations.

Disclaimer: this may not apply in your country. In Mexico it is mandatory to be late.

Imagine that you and your friends agree to go out for dinner. You get to the restaurant on time (well, alright, you are 5 minutes late).

Of course none of your friends has arrived... You get a table and wait. Good thing they serve free totopos so you can deceive your hunger. After half an hour the first friend appears. And then another. The last one is about 2 hours late. Of course, you cannot order until everyone is there. And they take their time to decide. You finally get your food 3 hours after entering the restaurant. It is your fault, for being on time.

The solution: next time try to guess how late everybody is going to be and arrive even later, so you don't have to wait for anyone.

So? It's dinner, why should everyone be punctual?!? Are you some kind of punctuality nazi?!?

The problem is that the same thing happens in business activities. One person arrives late to a meeting, causing everyone else to be late to other meetings, in a snowball effect that makes everybody's daily agenda as accurate as the Romanian train schedule. But that's fine, everyone understands and everyone does it.

It gets ugly though when you apply the dinner scenario to employee work hours. Most of the companies in Mexico turn a blind eye to employees that arrive late. 40 minutes, one hour, even more. You can always blame the traffic.

Why would a company do that?

Because they know they can ask them for extra hours on a regular basis, without extra pay. So they are expected to stay late daily and work weekends once in a while.

So it would seem like a WIN-WIN situation: employees can be late and the company gets free extra hours - everybody's happy!

WRONG!

The employees that DO get to work on time are the LOSERS! They get the same treatment as the other ones. Extra hours, weekends, everything. And they actually seem less "involved" with the company if they leave on time at the end of the day. Yeah, everybody knows that staying late is the measure of your commitment to the company. Being on time doesn't matter... the boss is not there to see you.

Of course, the boss arrives as late as possible too.