So you need a new Windows application. You fire up Visual Studio, but which project type do you select? Windows Forms application, or WPF application?

Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.

Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.

Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.

Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.

There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.

My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.

The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.

In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.

If you want to know how to estimate without using time units, here's how I do it:

For my work, I block out half-day chunks of time. I find that I can do some tasks in that half-day chunk (1, 2, or 3), and finish enough on any one thing that I can safely mark it as done enough and go on to the next task.

Some days, I have tons of little things to do: return calls, make lists, prepare to do something. Some days I have larger tasks: write a blog entry, draft a workshop, write a ton of email. Some days I have quite large tasks: draft 1 of a piece of a chapter, draft 1 of an article, draft 1 of a report.

Most weeks, I have a mix of things that are small, medium, and large. I no longer worry or estimate how long any of these things will take. I know about how many of the small, medium, and large tasks I can finish in a week. I can make my lists taking that into account.

If you are a developer or tester or BA or technical writer or a whatever (don't want to leave anyone out :-), you can do the same thing. Here's my recipe:

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

Now you have a little recipe for getting the tasks done. Here's how you apply it to your estimation. When someone asks how long something will take, you look at all your little tasks. Make sure they small, medium, or large, where large still fits in a half-day. You get no more than 10 half-days in a week. How many of these tasks can you do in a week? Add them up, and there you have your estimation without having to define how many hours a given task is.

If you're part of a project team, and want to try this on a larger scale, I particularly like the Fibonacci series (1, 2, 3, 5, 8, 13, 20) for estimating how large and complex a task is. As a team, use a Delphi approach (everyone gets together and as a group agrees on a number. For me, and when I teach my estimation workshop, any task larger than a 13 means "we have no clue and 20 is as good a number as any other number." When you hear someone is a specialist and can finish something earlier,  take the larger of the two values.

Other folks use t-shirt sizing: XS, S, M, L, XL, 2XL, 3XL. I don't like that as much, because, in my experience, teams don't learn to break tasks down enough, and have too many M, L, XL tasks. YMMV.

Now, it doesn't matter if you work in iterations or not. Take a week. As a group, ask "How many of these tasks can we do in a week?" Discuss the question. Arrive at a number you can all live with. You're done!

Remember that estimates are guesses. They are likely to be wrong, especially if you use time-based units. That's because we are either optimists or pessimists and because we never have ideal hours, days, or weeks. Try this and see what happens to your estimations.

I've been traveling, at three conferences in three weeks. At some point during these weeks, a few people asked me, "What's the difference between a technical lead and a first line manager?" Given their job descriptions, which include helping people manage their careers, seems to me that the answer is $10,000-$20,000. That is, the technical lead was being paid less, but doing the same work as a manager.

Ok, maybe I'm being a little cynical. Wouldn't be the first time today :-) But, I don't think anyone is restricted from being a technical leader. That person doesn't have to manage people or help them manage their careers. My opinion is that anyone who is responsible for results generate by other people is some kind of manager.

But a technical leader, is in Jerry Weinberg's words, "Leadership is the process of creating an environment in which everyone feels empowered", from Becoming a Technical Leader.

The people I spoke with did that. They also did many other kinds of work, including leading design/architecture work, which is what many of them thought the tech lead job was. But if you think about creating an environment, you can see that if you facilitate a decision, you're a technical leader. If you make it easier to ask for support or help, you're a technical leader. If you ask for whiteboards or chairs or some other tool, and that tool makes it easier for people to work and collaborate, you are a technical leader.

I wish organizations would stop using the term "tech lead" to stop paying first line managers what they are worth. I wish more people would exercise their technical leadership muscles.

Just remember, it doesn't matter what they call you, you can be a technical leader.

I'm not a fan of multitasking. There are plenty of studies that show that multitasking slows you down (links at the end). But you may not know what to do instead of multitasking. Here are some ideas:

1. Take a few minutes and write down everything you need to do. Part of speeding up is to make conscious decisions about what work to do when. If you are ever surprised by a particular piece of work, make sure you collect all the work somewhere, written down. I like to write everything down on a list on a legal tablet, just to make sure I have it all. I don't recommend stickies, unless you post them all on a wall and then transcribe them to a piece of paper. You want to make sure your list doesn't vanish onto the floor. Index cards are good because you can shuffle them, if you need to.
   
2. Now, what's your first thing to do? If you have six #1 priorities, either have a discussion with your manager in a one-on-one, or decide. I usually decide, because it's easier to ask forgiveness later than permission before.
3. Now you can do some work. For each piece of work, is it a task? If so, fine. Make sure you break your tasks down into very small chunks. You want to get to the point where, if you have five minutes, you can accomplish something, even if it's not very much. You want to finish something so you don't have to remember where you were on that task.
4. If the work is not a task but a small project, what's the first thing you need to do? How long will that take?
   

My rule of thumb is to use inch-pebbles or tasks that are even smaller, to make headway. You want to get to the point where you are in a wait state on a project so that you can move to another project, do some work on that, get to a completion/wait state there. The more wait states you get to, the more options you have as to what to do next. That's what allows you to speed up and not multitask.

Whatever you do, don't multitask. If you don't believe me, here are some links about the uselessness of multitasking: http://www.umich.edu/~bcalab/multitasking.html

In addition, here's a recent article discussing how people who think they are good at multitasking actually are not:
http://news.bbc.co.uk/2/hi/8219212.stm

More about multitasking: http://idiacomputing.com/moin/ContextSwitching

If you're part of an agile team or a manager, or in a technical leadership position, or you work with people, you'll be in a position to coach at some point.

When you start thinking about coaching, remember this:

Coaching is offering options with support

Coaching is not just teaching. Sometimes, coaching is listening, sometimes it's offering an example, sometimes it's helping other people see that there are other options. Once you get past sports coaching, coaching is much more than teaching.

So, how do you offer options with support? Consider these ways:

1. Help the other person see that there are at least three alternatives for each problem. There are more, but three is the minimum. Once you get past the third option, it's easy to generate more options for the solution.
2. Help the person work through the results/consequences of each choice.
3. Suggest a timebox in which to try the solution and see what happens.

These are all supporting actions.

Here's how I did this once as a manager. I managed a sharp guy who asked our management embarrassing-to-them questions at all-hands meetings. My manager told me I needed to fire him. I said no, that I would give him feedback and see if he wanted coaching. When he said he wanted coaching, and that he wanted coaching from me, I first asked, "Can you see three alternatives to how you ask questions now?"

He replied, "Well, I could quit going to the meetings." I asked, "Will that work for you?" "Not really." "Ok, that's one option, but it's not the best one. What's another option?"

"I could write down my questions at the meeting, and ask you later." I agreed that might work. I asked, "How frustrated do you think you might be by not asking questions right then and there?" "Very!" "Ok, so that's another option. Can you think of a third alternative?"

"I could sit next to you and whisper my question in your ear and you can tell me whether it's ok to ask." I agreed I would do that, as long as we would discuss why I said no to some questions at our next one-on-one. He agreed.

There were probably other options, but that one worked well for us for several months. I wouldn't say my colleague is the most tactful guy now, but he has a better idea of what works in public and what doesn't work.

Helping him think through the alternatives was a much better idea than telling him what to do or not to do. When it's time for you to coach, help the other person consider multiple options and support that person through the thinking and doing.

I've been mulling over the implications of the news that Sun's JRuby team leaders, Charles Nutter and Thomas Enebo, are leaving Sun because of uncertainty about the future of their project after the Oracle acquisition. They will be joining Rails specialist Engine Yard. This is the key quote from Nutter:

To be honest, we had no evidence that Oracle wouldn't support JRuby, but we also didn't have any evidence that they would.

JRuby is by all accounts excellent - I'm aware that developers at ThoughtWorks use it, and Ruby advocate Martin Fowler (who works there) told me that it works very well for them, observing that some enterprises who would be reluctant to deploy the native Ruby runtime are more comfortable with running Ruby applications on the JVM (Java Virtual Machine). It is foolish of Oracle to let the JRuby guys slip away, particularly bearing in mind the trend towards dynamic languages (like Ruby) rather than static-typed languages (like Java).

What does this suggest about the future of Java itself under Oracle's stewardship? If Oracle could have done more to reassure Nutter of its continuing commitment to JRuby, so too it could do more to reassure the rest of us that investment in Java and its community will continue as strongly under Oracle as it did under Sun. Maybe it will, maybe it won't; though culturally I suspect the new company will be averse to Sun's habit of investing heavily in projects with little obvious potential for direct revenue. The failure to monetize Java fully, along with the failure of its bold experiment in open source, is one reason for the acquisition itself.

That does not imply that Java will go away - Oracle itself is a heavy user, and defending its future was likely a factor in its willingness to purchase Sun. Still, it would not be surprising if the community is a little less warm, and Oracle's investments more focused on its own needs rather than those of the wider platform.

Despite Oracle, there is no reason to be gloomy about Java's future. There is another way to look at the move of the JRuby team, which is that they've found a way to continue working on the project with or without Oracle's support. Java is bigger than Oracle, just as it was bigger than Sun. 

IBM worked tirelessly to free Java as far as possible from Sun's control, developing its own JVM and creating the Eclipse tools project to foster alternative tools and frameworks. Those efforts will have a new context and relevance.

Maybe Oracle will do great things for the Java platform. Maybe it will do little, and momentum will shift to those outside the home company. Either way, investment in Java development is as safe as anything can be in our uncertain industry.

 

 

I have too much to do. It started back when I got the flu and bronchitis back in January. I was sick until mid-March. But even if you're sick, the work doesn't go away. Even working at full speed from March until now (end of June), I'm still behind. Here's my plan for getting out from under:

1. Brain-dump everything I have to do onto one (well, could be several!) pieces of paper. This is from David Allen's Getting Things Done.
2. If I have due dates, make another pass and put due dates next to things, so I can sort by relative importance.
3. Organize the list by importance if necessary.
4. Use Mark Forster's autofocus system to do what I can and what I have energy for, until I either reach a timebox or a wait state.

I know what I have to achieve, if there are dates that I have to meet, and I have my entire todo list in front of me. Now all I have to do is finish things :-)

Hope for green shoots of economic recovery, especially within the IT sector,  are likely to be further bolstered by the Government's Digital Britain Report, which has pledged to invest 23m to encourage smaller businesses invest   in IT in order to help improve their business.

As the potential demand for IT workers, both permanent and contract, looks set to reflect a small rise in demand, candidates may find themselves in a slightly stronger position when it comes to negotiating terms than they have been in the recent past.  If so, it's important to keep a few points in mind:

Firstly, research. If negotiating money, candidates need to be aware of the current jobs market - what's available and how reasonable their current rate is. This may have changed in recent weeks and months so be sure to keep a constant eye on the market.

Secondly it's important to be sensitive to your employer's current state. If the organisation has or is looking to make redundancies, or has posted poor financial figures recently, it may be unreasonable to even approach a discussion about higher pay rates. 

Also, candidates should look at their skills set and their experience and gauge this against the current jobs market and their colleagues in similar positions. Be clear about your skills and qualifications and your experience within an industry; it's important to be absolutely sure how these benchmark you amongst others in your specialisation.

Finally, it's important to maintain a sense of perspective. The Government investment will certainly be the first helpful step on the road to recovery, but it is, after all, just that - a first step. Employers are still likely to be cautious when it comes to making new hires and deciding what financial commitments they are willing to take on, so be willing to compromise where necessary.

I've just completed several weeks of conferences and in-house training, and I'm finally back home for a while. It's amazing to me how many sources of inexpensive learning there are.

1. Conferences. Conferences are amazingly cheap for learning about a wide variety of topics and techniques, especially because you have an opportunity to network with and speak with not just speakers but all the other people at the conference. If you use your time well, you can meet people in a similar position as you are, and learn from what they do. The speakers generally take excerpts from their workshops to use in tutorials, so you have a chance to audition the speakers. Think about it: it may cost you a max of $3000 to participate in a week-long conference, assuming you did not take advantage of early-bird discounts for registration and travel. If you learn something at a conference that saves you a week of work over the course of a year and you tell one other person about that tip and it saves them a week, you have more than made back the cost of the conference. Many of you are probably thinking I've gone off the deep end (since when is $3000 cheap??), but think about the potential return.
   
2. Books. Books that are well-written and explain how to do things first, second, third, are worth way more than their cover price. And, given the electronic readers and pdf books out there, I'm astonished more people don't buy books as a matter of course, when they want to learn something. It's hard to get cheaper than a book, but some local meetings are free.
   
3. User group and other affinity group meetings. If you would like to learn about a small area in a field, check out some user group or other group meetings, such as agile, or testing, or project management. Generally, the cost to attend a meeting is about the cost of a book, maybe a little more depending on how nice the dinner is. You will not get the breadth of a conference or a depth of a book, but you will learn something. BTW, if you are looking for a job, these groups are also great for networking.
   

You can also learn from searching the web, and it's harder to know if what you are reading is correct :-) So before you think there is no money to learn new things, rethink. See what ways are good for you and fit your budget.

And for those of you with conference money, I'm a host of the AYE conference, and the conference chair for Agile 2009.  

I was speaking and teaching last week at the PMI Regina's PDC (Professional Development Conference). I taught an estimation workshop and we had some illuminating discussions about what to do when people on your project can't estimate. We all agreed people tend to be either optimistic estimators, where they think the work will take less time, or they will be pessimistic, where they think the work will take longer. Rarely does someone change. Our discussion about what to do when someone consistently miss-estimates was the part where I saw servant leadership.

One project manager said, "I don't want to crush someone's hopes or ignore their hard work, but how do I explain that each and every assignment he's been late on and I just don't believe his estimate?" Good question.

People need feedback on their estimation, and a project manager might be able to help the person see where this estimation suffers from the same problem as the previous estimations.

That's where the servant leadership comes in. A PM who's not a servant leader will think, "Hmm, your last 5 estimates have been off by 50%. I'll add 50 %," and be done with it. But a PM who is a servant leader gives feedback and asks for a re-evaluation, "Joe, you might not know this, but your most recent 5 estimates have been under-estimated by 50%. I don't want to blindly pad your estimate. I'd like to help you learn to estimate better. Is that ok?"

If that's ok with Joe, now you have a way to help the other person learn to estimate better. I like breaking tasks into inch-pebbles (one- to two-day tasks that are either done or not done), starting with user stories, or using Delphi estimation as a way to help people learn to estimate smaller tasks and see when that work is actually complete. One guy I worked with said, "I always thought it just took a few minutes to set up a new branch. But when I tracked what I did, I realised it took me closer to an hour, by the time I was actually done and ready to start writing code and tests. Who knew?" Until he created inch-pebbles he had no idea how complex his work actually was.

Great project managers serve the project and the people on the project. They don't take estimates at face value, without understanding how the estimate came to be. But they don't autocratically change the estimate without providing feedback.

If you're a leader in the organisation, whether you're a team lead, a project manager, or a manager, think about how you can serve the project, the organisation, and the people. You'll get better results if you remember the people.