Over the past three months, we've noticed a desire for job security among candidates with an influx of IT staff looking to work in SMEs. Over 70% of IT placements made by Computer People in the past three months have gone to Britain's small businesses. As the economic downturn deepens, it seems that  an increasing number of  IT staff are turning to SMEs to provide them with a different career path and new opportunities.

Though the IT industry isn't immune from the effects of the economic downturn, one thing we are seeing is that it is unlocking talent that would previously have been unavailable for firms at a certain level to reach. Much as we saw happening in the City at the tail end of last year, high-flying professionals are now reconsidering careers with bigger firms, and are instead considering the perceived security of SMEs.

With 13.5 million people working within small businesses in the UK, the phrase' good things come in small packages' is becoming more and more applicable. IT professionals in particular are keen for a greater level of responsibility, ownership and variety in their day-to-day job, something they believe the SME market can offer them.

Technology based SMEs have proven to be extremely attractive to candidates keen to take their career to the next level. SMEs offer professionals a chance to make their voice heard and see the benefits to the business first hand.

A colleague asked me about my worst interview experience the other day. He wanted to contrast it to his, to see if he should be offended :-)

Hiring managers, HR folks, interviewing people are all people. So, it's not surprising that sometimes we don't find them at their best. Here are some of my worst interview experiences:

When the hiring manager changed his baby's diaper during my interview. I was a developer in my mid-20s. I had not babysat for small children, and had no idea about small children. The hiring had brought his toddler into work that day. During the interview, it was odiferously clear that the baby's diaper needed changing. The manager changed it while I was answering questions. Then, worst of all, he left the diaper in his trash next to his desk. The room stunk.

I know a lot more about babies and stinky diapers now :-) But I decided any manager who left the diaper in the trash in the same room as an interviewee was not to be trusted. Managers have the job to create a great environment for their staff.

Sitting in a stairwell because there was no other place to talk. Back in the late '90s, I was interviewing for a consulting engagement. The manager had offered her office to her staff for a meeting. (A reasonable thing to do.) But that left us with no place to sit. She suggested we sit in the stairwell. "No one ever goes there." Well, plenty of people did. I suggested we find a place to have coffee instead, but she persisted. We never did discuss the confidential issues.

No lunch in interview that started 9:30, and ended at 2:30pm. Back in my project management days, a recruiter called me, and pleaded with me to go on an interview. "The job was made for you." I finally agreed, and planned to spend most of a day on the interview. At 1 pm I asked about lunch. "Oh, no one's got the job of feeding you." I suggested we go down to the cafeteria, and I would buy lunch while my interviewer interviewed me. "I'm too busy. Just go yourself."  So astonishing on so many levels.

Not having anyone ready to interview me when I arrived. I arrived on time for my interview, but no one knew who was supposed to see me first.  I gave them 20 minutes and left. If they couldn't figure out how to get going in 20 minutes, this was not the place for me.

Having the interview location change, but no one told me. I was interviewing at a large company with a "campus." I'd discussed the location with the HR person earlier, and when I showed up, the security guard gave me a map and told me to drive 10 minutes away. Now I was late. And, so was my interviewer.

I hope none of these happen to you. If you're a hiring manager, know what you have to do to avoid these problems. If you're a candidate, decide what you can and cannot live with. 

It is one of the dirty secrets of software development: the number of memory leaks that find their way into production code. Memory leaks are a special category of bug because they can easily go unnoticed. The user's perspective is that they start work using your application and everything is fine. If it is an application that is used lightly, maybe run once every morning to create a report, than everything is fine for ever. If it is a long-running application then eventually it will cause problems, though the user may not know which bit of software is to blame. Since Windows rarely runs out of memory, the user might just notice everything slowing down. It is one of the reasons why restarting Windows from time to time tends to be beneficial.

The huge amounts of RAM in today's machines disguise memory leaks. An application can leak a little bit of memory with every operation, and still run fine for ages. That's not good though; and the migration to web applications makes the problem worse. Web applications tend to be exercised heavily for long periods, which means memory leaks are more likely to have severe consequences.

Although garbage collection in the .NET Framework is meant to relieve developers of the burden of memory management, the reality is a little different. In some respects managed code is more prone to memory leaks than unmanaged code. The problem is that the garbage collector will only free objects for which no valid references exist, and it is easy to maintain such references inadvertently.

So how do you find these guys? You observe memory usage externally with a utility like Sysinternals Process Explorer, or write your own tests with code such as calls to GC.GetTotalMemory, or use a dedicated tool. There are performance tools built into some versions of Visual Studio, which can be configured to do .NET memory profiling, though making sense of the reports takes some effort. If you want to try this in Visual Studio 2008, open the Performance Explorer, right-click a Performance session, and check the boxes for .NET memory profiling collection. This can be useful, though I'm going to suggest a third-party tool which is modestly priced and more productive: Scitech .NET Memory Profiler. Others worth investigating include Micro Focus DevPartner Studio (which does far more than just memory profiling) and Rational Purify Plus.

Here is a quick example. Let's say I'm writing a VB.NET Windows Forms application. I have a main Form1, and a second Form2 which I create and display as needed. I want to have the second form respond to events on the main form, so in Form2 I declare a reference to Form1, which I set when Form2 is displayed:

Private WithEvents mainForm As Form1

Using the Visual Studio editor I hook up an event handler for mainForm.

Everything works fine, until a user complains that the more she uses the app, the more her machine slows down. What's the problem? Well, if you run the Performance Explorer with memory profiling enabled, you might notice something odd. Run the app, and display and close Form2 three times over. The report tells us (among many less useful things) that there were three instances of Form2 created, and that all three were alive at the end. We've found a memory leak.

 

What's the problem? You can guess that it is something to do with the reference to Form1. The Scitech memory profiler easily identifies the exact problem. In order to find it, run the application in a Memory Profiler session, then immediately choose Collect Heap Snapshot. Open and close the three instances of Form2, then again Collect Heap Snapshot. Finally, filter the view to show new or removed instances only. You can see that the number of instances of Form2 is now 3, where it should be 0. Double-click this line in the report to see a list of instances, and double-click the first to see the references to it that are preventing it from being garbage-collected. Although there are several of these, only one really matters, which you can find by checking the option Only show instances included in root paths. The culprit is an instance of System.EventHandler.

 

You can actually fix this memory leak without changing the way the app works. Remove the handles clause from the event handler for the mainForm reference, and replace it with a manual event hook-up in the Form2 constructor:

AddHandler mainform.Click, AddressOf mainform_Click

Then, override Dispose and manually remove the event handler:

RemoveHandler mainform.Click, AddressOf mainform_Click

Try the application again under a profiler, and you'll see that the problem has disappeared, and no instances of Form2 remain in memory after it is closed.

No doubt there are other, better ways to code this application; but it illustrates the troubleshooting process.

The reason this kind of leak is so troublesome is the chain effect. If a form remains in memory, so too do all the objects referenced by that form, and so on. Unfortunately there are occasionally bugs in the Framework itself that make this hard to avoid - see for example this post by the author of Memory Profiler, Andreas Suurkuusk, where he tracks down a problem with the toolstrip control.

I'd argue that .NET applications of a significant size are more likely than not to have some memory leak issues, and that a tool like Memory Profiler is near-essential for troubleshooting them.

I would love to know enough about my projects to predict them perfectly. But, I rarely do. That's why I use rolling wave planning, no matter what life cycle I use.

In a serial life cycle (waterfall or phase gate), you can lay out all the major milestones if you know what they are. But you don't plan in detail how you get to each milestone. Instead, you plan for the next 4 weeks--no more than 4 weeks--in detail. The way I do this is:

• Get everyone on the project in the same room
• Decide on a milestone (not necessarily a major milestone, just a milestone) that's a month away
  
• hand everyone a thick black marker and a pad of yellow stickies. (I need people to use the 4"x6" stickies because I can't read what they write on the smaller stickies. If you have people with younger eyes, use whatever size stickies you want :-)
• I ask this question "What will it take you to achieve this milestone?"
  

Then I get out of the way. I let people write their tasks down and argue about who has to do what. I make sure no one starts a physical fight. If we have questions, I keep a parking lot of stickies on one side. I ask people to put their stickies in time order, left to right with the earlier tasks on the left and the later tasks on the right. If there are dependencies, note that with sticky placement.

I request that people create small tasks, inch-pebbles (one- or two-day tasks that are either done or not done). If people have week-long tasks, I work with them individually to break the tasks down into smaller pieces. 

What you have now is an on-the-wall-sticky Gantt chart. But you only have 4 weeks worth. Now you have a couple of choices of how to proceed:

1. You can either ask everyone to get together to do this planning for one more week every week, or
2. You can ask people to plan their own tasks weekly and once you've achieved a major milestone, now you get everyone back together.

The key is that you always have a month's worth of detailed planning. You never have more. You never have less. If you laid out the major milestones, everyone knows what they're trying to achieve as a group. If you're managing the project, you have much more insight as to how well the plan is going vs. the actuals.

With an iterative life cycle, such as the spiral life cycle or RUP, or with an incremental life cycle such as staged delivery or EVO, this is even easier, because these life cycles deliver prototypes or finished code into the code base earlier.

With an agile life cycle, I use rolling wave planning not for the schedule, but to better my prediction about which features might be delivered in which iterations (assuming the product owner doesn't change his/her mind much about the ranking of features).

No matter what life cycle you choose, consider adding rolling wave planning to your toolbox. Especially if you can't predict much. You don't have to, and you gain tremendous benefit by seeing the details for the next few pieces of work.