Pawel Brodzinski on Software Project Management

What Would Be Your PM Approach: Glen Alleman

2009-07-01T21:44:00.002+02:00

We have another set of answers in what would be your PM approach series. This time opinions from Glen Alleman who runs a great blog called Herding Cats. This should be a must-read for everyone dealing with project management, especially for those boxed in one approach. Glen’s thoughts are very insightful and personally I value much our discussions, no matter whether we agree on subject or not. He has also pretty unique background since much of his work is done on huge projects being delivered for institutions like US Department of Defense.

Here are Glen’s answers. There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

Do we have all the necessary resources for increasing the probability of project success? The Prince-2 process depends on the pre-conditions for success being in place. I’d start with a chartering session where the stakeholders are present. ALL the stakeholders in the same room at the same time. Then, using Prince-2, capture the top level business requirements (business capabilities) in a working session. These top level requirements must not be technical in nature, but must be operational and tied to the success of the business. The units of measure of this success must be meaningful to the stakeholders. They must agree on these units and the beneficial outcomes of the project.

Take these requirements (capabilities) and create a requirements management „tree” in some requirements management tools. These „Tier 1” requirements are owned by the business and the stakeholders, since they are not technical.

Following Prince-2 (which I not experienced at) I’d make sure I had a process advisor on the team that could train, support, guide, and advise all the team members on the various activities inside the method.

But as Project Manager, following the method is necessary but not sufficient. I must have the full attention of the customer at least on a weekly basis to confirm we are making physical progress in accordance with the agreed upon „Tier 1” requirements.

As a process I’d focus on driving every development effort through the requirements traceability to the delivered code elements.

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

I’d start with the business side of the house and determine what in their view has been the problem in the past. Research shows that requirements management is a fundamental problem from firms like this to the US Government.

The simplest project management methods are based on making visible what „done” looks like, measuring „done” in units meaningful to the stakeholders, and assuring that these measures occur on fine grained boundaries. The first principle is any successful project – beyond defining „done” – is to answer „how long am I willing to wait before I find out I’m late?” This is the basis of ALL good project management methods. From Ron Jefferies XP to NASA and US DoD 5000.02 Integrated Master Planning.

I have direct experience in this scenario at a large (100) US Department of Energy Nuclear Clean Up site IT project. Define what „done” looks like in a „plan of the week.” Hold each team member ruthlessly to meeting the „plan of the week.” On the Thursday prior, assess progress for the week and reset the „plan of the week,” for the next week.

Weed out the low of non performers on the team. Get the 70 down a leaner 50 or so. Partition the project into separate parallel streams with minimal coupling but maximum cohesion. Do this through a small (1-2) architecture team – handpicked by me, but agreed on by the stream leads.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

As the architect of a fault tolerant process control system I have direct experience in this scenario.

Hire the best damn high availability developer I could find, have a clean and testable architecture, get a toolsmith to support us for everything that gets in our way, build an incrementally developing „simulation” platform to validate and verify the code every day. No one leaves the building until our daily build works against that „test platform.” Repeat daily. XP or Scrum like process work well here as long as the customer is on the team, but doesn’t count as one of our 4.

You can find other people answers grouped in what would be your PM approach series.

PMBOK Can Be Agile Too

2009-06-26T18:53:00.000+02:00

I was a part of hot but interesting discussion yesterday on agile community meeting. I was trying to show situations where agile doesn’t have to be a perfect solution. On the list of examples there were one-man R&D project like these done in Google and a tiny startup. A point I made was agile methods are too strict for these environments – you don’t need pair programming, daily stand-ups or 2-week sprints there.

Then the whole thing started. People went with argument that it’s not about every single technique which is a part of Scrum or XP. As far as we’re aligned with Agile Manifesto we’re still agile even if don’t follow every practice. And if some values from “the black list” of Manifesto are important for the customer (e.g. documentation) we should put enough focus on that.

At the first moment I got lost a bit. We can switch anything off as far as it does make sense or is forced by the customer and we’re still agile. Well, this actually means we can have pretty much formalism around which, if I remember correctly, was something agile was trying to avoid.

After a while I changed my mind. Hey, it’s me who advise you to take only tools which works for you in specific situation. It’s me who advocates for common sense in project management above following any rulebook. I definitely wouldn’t tell you to blindly follow any methodology.

This approach however means that you can call agile pretty much any methodology out there. As far as your methodology choice is based on reasonable arguments – e.g. the client forcing you to use more formalized or more heavy-weight process you’re still agile. If you skip some practices because you can’t have stand-ups in the team spread geographically and you can’t relocate these people – that’s fine. You’re still agile. If you put much focus on process to align with the rest of your org you can still say how agile you are.

That actually means you can use PMBOK to run your projects and basically be agile. You can have one of more formalized methodologies and be aligned with values of Agile Manifesto at least in these places where it’s under your jurisdiction. Which makes the whole holy war around agile quite irrelevant by the way. If that’s exactly what my adversaries were trying to convince me to I have to admit they succeeded. However I’m not sure if they would go that far even though that’s only interpretation of their arguments. After all I don’t consider myself as agile expert so I have to base on opinions of these who do.

A disclaimer: I do appreciate agile techniques. I believe short cycles are better than long ones. I think that everyday communication within a project is a must. I hope to see my team working with Kanban soon. And hell no, I don’t consider myself as agile-hater although I was probably labeled that way yesterday by a few people.

What Would Be Your PM Approach: Jurgen Appelo

2009-06-24T20:19:00.002+02:00

Today we have Jurgen Appelo who briefly says what would be his PM approach in different situations. Jurgen runs a great blog – Noop.nl – which I advise you to subscribe if you haven’t done it already.

There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

I might start with XP practices, because project management (Prince-2) is already in place, and could be changed (slowly) to be more agile later. But good technical practices would be higher on my list because of complexity of project.

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

I would start with Scrum, because that is a relatively easy step to take to bring some structure to an organization.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

I would start with both XP and Scrum at the same time, because when you start from scratch it is easiest to do everything right from the start.

Pretty brief and concrete answers. I hoped to get this type at least once and here they are.

Keep an eye on whole what would be your PM approach series.

What Would Be Your PM Approach: Shawn Futterer

2009-06-18T20:35:00.003+02:00

This is the first set of answers for the same three questions I asked several project management experts. These are thoughts of Shawn Futterer who is a director and the main person standing behind the ICPM (International Community for Project Managers) site which is a great place for all of you who look for high-quality PM content and resources.

There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

I would have to say that in the given circumstance, I would use the following tactics:

1. For Team building, I would host a function outside of the workplace to allow the team members to get to know one another on a personal level. This should lend itself to improving team performance, boost morale and generally keep spirits high.

2. For Team Work I would hold more frequent team meetings. Whether in person or virtual the coming together of team members to discuss status, challenges, roadblocks and successes is crucial in creating a cohesive team environment. If the company standard was 1 meeting per week, I would hold 2 until such time as I felt the team was functioning like a well oiled machine.

3. For Schedule overruns, I would first define the critical path and then employ some techniques such as schedule crashing or fast tracking, running any tasks in a concurrent fashion that can be. These are basic PM techniques. A more advanced approach could be something such as this personal practice of mine; when working with consultants, vendors and outsourced partners I like to define contract terms based on performance. Rewards for exceeding goals and penalties for missing deadlines. This assumes the PM has the ability to source and select vendors. This is fine and good to motivate the vendor to exceed goals and meet deadlines, but it does not help a project that’s behind schedule get back on track. For that we need to start with the basics, Crash and Fast Track. In extreme circumstance we might need to reallocate or swap resources from non-critical tasks to those that are behind schedule. We might need to simply work overtime. This may cause us to go over budget though, so we need to be wary of this. We should absolutely review all upcoming tasks for Float and cut where we can.

4. For budget overruns, I would determine if the budgetary overrun is a result of scope creep. In my experience this is often the case. If scope creep is an issue, we need to institute tighter change control policies. This can dramatically impact our project and keep costs down. Next I might look at things like: material costs and determine if they can be reduced. Are we working overtime? If so, can it be cut down? Do I have salaried employees that can put in extra hours in exchange for time off later? Lastly, a best practice is to calculate a budget contingency when you’re first assigned to a project. Every good PM knows he/she should expect the unexpected. It’s never a bad idea to try and negotiate for a contingency fund for just such cases.

5. In the end if we finish over budget or behind schedule, internal processes need to be reviewed. This, again in my experience, is often a cause for concern. Which process can be improved to have a positive impact on our approach to Project Management in general?

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

In this circumstance I might employ the following:

1. A company of 70 people does not require a long drawn out methodology for PM. In this smaller company environment, a projectized approach to PM is desirable, in my opinion. We would use a simple 1- or 2-page methodology to address the basics such as project charter, funding approval, quality control and change control and close out. First thing a small company needs to do is determine whether or not they should take on a new project. Some simple ROI and earned value calculations should be performed. Once a project is accepted, the PM is responsible for it in its entirety. Now we are able to institute some basic PM best practices including milestone definition, task management, team selection and resource allocation and performance management.

2. As with any project, some tasks can be run concurrently, while others have start-stop dependencies. When working with software it’s crucial to define task start-stops and hand-offs to downstream programmers.

3. Scope Management is also crucial. Small companies can be more susceptible to scope creep raising from a desire to satisfy their consumer or marketplace. Change control policies need to be defined and tightly tied to the funding approval and scheduling processes. Change scope only if it makes sense. Importantly, make sure the project sponsors approve scope changes. All other items should be addressed as a separate project in a later phase.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

This is project management 101, in my opinion. I’m not stranger to a start-up with limited resources, a fast paced schedule to get to market, high quality aspirations, tight budget constraints and the list goes on and on... In this scenario, it’s important to create work packages, distribute responsibilities and work load balance. By taking time upfront to define common practices, the start-up saves time and money down the road. Answering questions like “How will we do things?” “Why we will do them that way?” and “What benefits does this method create?” are a good way to start to define yourself in a startup. Create your methodology as a pathway to success.

There is a degree of value in researching and thinking about your business in a systematic way. Planning helps you to think things through thoroughly. Learn to be critical of your own ideas, this should help ensure those that you implement are sound. Collectively as a group we should determine our PM approach. As it relates to software, do we use SCRUM, Agile, Xtreme programming, or something else? We need to define the iterative process and then incorporate that into our methodology.

In this scenario, there are four people in the start up and there will undoubtedly be more than 1 project going on at any given time. I’ve had a degree of success in having each partner act as a traditional Project Manager where each is assigned to lead a project or a phase of a project. This helps with my points above about responsibilities and workload balancing.

These are answers from Shawn. Soon there will be other opinions on the same problems.

I encourage you to keep an eye on whole what would be your PM approach series.

What Would Be Your Project Management Approach

2009-06-18T20:26:00.006+02:00

When it comes to decide which project management approach is best I believe there’s no silver bullet. I’d go even further – in any given specific situation there’s no such thing as ideal approach or a single method which would work best.

I have this thought in the back of my head for some time and I decided to find some arguments either for or against this theory. I decided to ask several industry experts and bloggers the same few questions. How they would act in three different situations.

I’ve chosen people with different experience working in different businesses. I’ve done it on purpose. Usually solutions we believe are the best differs basing on our past experience, knowledge and things which worked for us in the past. What more we all are biased in some way, which also influence paths we choose.

Situations I’ve chosen are different too. One is about big project in corporate environment, another is about cleaning the mess in fairly small company and the last one is about setting things up in a startup.

I’ll publish these posts once or twice a week. Below you can find all published so far.

Are You a Fan of Your Job?

2009-06-16T18:13:00.003+02:00

Lech from Progress Blog, as usual, made me thinking after his recent article about working in structured environment. One thread especially stuck with me – a question whether we are fans of our jobs and why so many of us aren’t.

In his article Lech presents typical cycle of our jobs – at first we’re all open and positive about our new role. Then we slowly start drowning with our commitments and unfinished tasks and finally “smile is no longer there, the attitude is no longer so open.”

I agree, I’ve been there. Probably most of you who went through a few different jobs know pretty well what Lech is talking about. The part which made me thinking wasn’t about losing positive attitude though. Actually it was all about initial attitude.

One of my friends recently summarized her new job:

“Well, that’s just a job after all. Of course it is important... from 8am to 5pm. I’m cured from being mentally at work all day long. I’ve learned to have a distance.”

If you asked me five years ago I wouldn’t understand. Hey, you spend half of your conscious life at work. You should be all hot about it! If your initial attitude is so low how do you expect to succeed? And what will be at the end? How would you feel in a couple of years?

That’s how I would react five years ago. And now? Well, now I wouldn’t be surprised. I still believe that positive attitude makes your day at work nicer but I’ve seen enough examples of exploiting people’s positive attitude, squeezing them like lemons and kicking them at the end of the day instead of saying simple “thanks.” I’m no longer surprised to see “cured” people.

And yes, people end up in jobs which they aren’t fans of. Why? Because they couldn’t find better ones. Because sometimes these are ones which are paid better. Because someone lied to them during interview. Because they’re thrown to a wrong team. Because their boss appear to suck. Because things change fast. There are more of non-fans than you’d think.

Many employers would eager to know whether their employees are fans of their jobs. But almost none of companies would do anything if they heard “no, not really” as the answer. Why this relation should be asymmetrical? Why should people care more than their employers?

But coming back to the question from the subject – I’d love to hear whether you are a fan of your job. Why? Why not?

And the other one – whether you were a fan of your job when you started it?

LiquidPlanner Review

2009-06-13T13:36:00.005+02:00

Today on Software Project Management review of one of project management tool which gets pretty much attention these days – LiquidPlanner.

Overview

LiquidPlanner is yet another project management web-based application which helps you to deal with your projects. Nothing new under the sun you could say. Well, yes and no. LiquidPlanner doesn’t stun you with a range of features but personally I don’t expect that from project management software. However it focuses on at least one specific area which is usually either overlooked or designed in crappy way – work estimation.

Strengths

Features

With LiquidPlanner you get all the basic stuff. There are tasks organized in a structured way so you can easily see what’s next and what’s then. There’s history for each record in the system which is a must-have for every application used in a bit bigger than tiny team. Security is fine. Dashboard is actually industry standard so I’m not surprised it is here too. Reports show all needed information. There are timesheets which is nice since majority of companies use them anyway in this form of another. The only glitch for me is lack of bug tracking. I believe people need as few tools as possible and bug tracking is connected with task management, especially when it comes to development and QA teams.

Task Estimation

LiquidPlanner does one thing particularly well – it forces users to change approach to task estimation. It’s not just one value anymore. For each task you fill a couple of them. A range of dates which shows when you plan to finish the task. This feature brings another thing to the table. Having a range of dates instead of a single one LiquidPlanner can generate reports which aren’t commonly seen in project management applications. You can see a “tunnel” of the most optimistic and most pessimistic deadlines and get an insight how they changes and how you perform between them. In other words you get the answer do you get better or worse and how fast you’re moving.

Task Management

Usually task management is limited to fill out records manually one by one or import ready MS Project file. LiquidPlanner gives you another thing – you can easily fill out many tasks in a simple text interface. That’s spare you a lot of time since you don’t wait for page reload after filling each record – you just fill them all at once and then watch how they make their way to the project plan.

Organizing Tasks in Project

Well, this one is a mixed blessing. LiquidPlanner tries to resolve conflict with resources (yes, that’s a perfect name for people you work with) for you. Now, that can be great when your team works on many not interrelated tasks since the tool should build pretty reasonable work plan for each person. However when you try to build work plan for one big ugly and complex project with many task-related constraints (as an addition to people-related dependencies) project manager will have pretty tough time to set things up properly. It just depends on a way the team works.

Timesheet Integration

Timesheets are integrated with task management so when people update tasks their timesheets are automatically filled. That’s nice since it takes one unpleasant duty off the people’s heads.

Weaknesses

Task Dependencies

OK, maybe it should go to usability glitches but it’s such a pain in the ass it deserved its own paragraph. Creating and editing dependencies just suck. It’s unintuitive, slow and inconvenient. Actually LiquidPlanner approach is you shouldn’t need to set many dependencies because the tool would automatically set most of them but that’s way too optimistic point of view. Projects have many specific constraints and resource conflicts are the only type and sometimes not even the most important one. Editing dependencies should be considered as one of key features in project management application. Period.

No Anti-Dating

This one was especially painful for me since I wasn’t actually working on project but just playing with LiquidPlanner. You can’t really fill the past data. Everything you do is done for now. My problem was I couldn’t fake some history of the project, but the issue is much more general. How the application deals with the situation when a developer forgets to update tasks for a couple of days (and yes, it happens virtually every day). While working with LiquidPlanner you have to keep pretty strict discipline, which often is neither easy nor necessary.

Small Usability Glitches

It wouldn’t be me if I didn’t rant on usability, right? Remember the problems I got when switched to netbook with low (1024x576) screen resolution? I caught several screens, including introductory video which doesn’t fit my computer. They’re just too big. There were problems with lists refreshing after something was changed. I know I can manually refresh the list but I’m just too lazy to be happy when I’m forced to do that. If I change the task in MS Project and save the changes it’s instantly changed on the list. In almost every other application data on the list somehow magically updates.

Summary

Usually first things I see when I start playing with an application are flaws. Quite often these are small glitches which are annoying until you get used to them and don’t bother anymore. Something which stays in the long run are big things – features you need, ability to cover scenarios which happen in your team or lack of significant bugs. That’s exactly how it was with LiquidPlanner. At first I couldn’t just add a project since my screen isn’t good enough for the application, then I struggled with organizing a project in a way I wanted and hit a dependency problem. But then, because of problems with anti-dating, I started to work with LiquidPlanner everyday for a couple of weeks and it worked smoothly. And it got the job done.

The most important thing you should remember while thinking about LiquidPlanner is discipline. As far as tasks are updated exactly when they have changed or they’re done and data is filled on a daily basis almost everything works fine. The question is whether you need or want to implement such a discipline.

LiquidPlanner is pretty mature tool and it does great job in project estimation. I can think of only one other application which focuses so much on that aspect, which is FogBugz with its Evidence Based Scheduling.

Is It Possible to Over-Communicate In Project?

2009-06-09T19:55:00.000+02:00

While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”

Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?

Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.

Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.

John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.

Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.

The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.

On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.

How does it look like in your teams?

Google Chrome and Rules of Software Business

2009-06-04T19:01:00.000+02:00

One of readers of Software Project Management, Travis, left a comment under my last entry about rules in software development business. He states:

"In my opinion, there are no rules in software development. I think a good example is Google Chrome. This application doesn't follow all the requirements of a web browser. Google decided to invent a new tool to browse the web, period. The menus are different, there are no add-ons, no this, no that. Google didn't follow the rules and so far, Chrome is doing great."

Actually Google Chrome is a great example of what I was trying to point. Browser business. Is it new? By all means no. Are there any common rules everyone follows? Hell yes. Does Chrome change the way we use browser? Are there any ground-breaking features? Is Google browser revolutionary? Sorry Travis, but no, no and no.

Our routes with Chrome are the same as with other browsers. We still click links and use tabs. Web is all about content, not about browser. Browser is just a tool which we expect to get out of our way. What a pity not every page works well in Chrome by the way. Either way it’s just a glitch which will be fixed by Google or, more likely, by website developers. I still don’t see anything revolutionary here.

Ah yes, it was intended as a lightning fast browser or at least significantly faster than competitors. I admit I didn’t do any benchmark tests to say for sure but I don’t see significant difference. I believe there is, but not at the level I would care about. And when talking about a real pain in the ass, which is resource consumption, Chrome doesn’t really rock. It eats roughly as much RAM as competitors. You just get a bit more control since every tab is run in different process, so closing the tab should immediately return resources to the pool.

What’s next? GUI is the most visible thing. But it all comes down to well... GUI design. Just look and feel. I agree it is better (less cluttered) and nicer (a very subjective thing) than both Internet Explorer and Firefox but is that a revolution? It’s just another skin for old well-know tool.

Chrome is an example of playing by the rules. But talking about Google it’s much easier for them to ignore rules even if they’re already set. The reason is simple – no matter how crappy service Google would provide there would be thousands and thousands of users which, in many cases, creates enough mass to start changing people behaviors. Now if the product happens to be good enough to make people stick with it behavior-changing process will gain velocity and market along with its rules will change.

If you aren’t lucky enough to be Google A.D. 2009 chances are good you won’t gather crowd big enough to make a change. That’s why, in vast majority of cases, playing by the rules is more reasonable choice.

Play by the Rules If There Are Any

2009-06-02T18:55:00.000+02:00

I have a lot of discussions on different business models these days. We end up fantasizing on usage of new revolutionary services or discuss how current ones will evolve and how we can exploit that.

One thing becomes pretty clear if you talk long enough with people on the subject. If there is existing business on some kind of service, let’s take mobile messaging for the example, you’ll have hard time trying to convince people to your new revolutionary service with new revolutionary business model standing behind. People will stick long with what they already know. Customers are driven with bonuses for preserving status quo. They won’t be rewarded for creating new markets. That’s sad but that’s true.

If you work in an area which is already quite well defined in a vast majority of cases playing by existing rules will be the best strategy unless you have enough power and persistence to slowly change the rules.

The situation is different when it comes to a business which wasn’t there before. There are no existing working business models. There are no rules. Mobile payments system in developed countries is a good example here. No one got it right yet. At least not in a way which can be copied. A result? Everyone strives to find the way, to find the best (or I should say the first good enough) solution. There’s no beaten track so everyone seeks their own path. Since there are no rules no one can play by them.

This is of course an overgeneralization but most of the time big companies deal better with situations where rules are already defined while small organizations (with strong focus on startups) do better job in undefined areas of business.

Which kind of market do you operate in? Well-defined or vague one?

Exceptional Customer Service

2009-05-29T19:42:00.000+02:00

Some time ago I saw seen this cliché in one of restaurants: “If it isn’t exceptional it isn’t good enough.” Besides I liked the phrase I didn’t believed guys from restaurant followed it. Actually I didn’t believe any company is able to function that way when it came to customer service.

Except it happens and I can’t deny it.

The other day I wanted to get car insurance. The problem was I wasn’t able to reach any insurance broker in my hometown during their working hours. Actually I couldn’t reach them during any reasonable hours since I was on the long way home and with no teleportation module in my vehicle I couldn’t make it before 10pm. On the other hand I didn’t want to leave the car with no insurance, just to sleep well.

I found only one broker who was willing to wait until evening for me. When I was finally there I was ready to sign pretty anything just to get the thing out of my head and get home. Actually the initial offer was pretty crappy but still I was ready to sign damn papers. The broker however wasn’t happy and she sought further until she was able to cut 30% off the price. It took her an hour of work. A late-evening hour. When we finally shook our hands it was 5 minutes past midnight.

It was just an extra mile she went for me. Or rather it was as much as an extra mile she went for me. What more, as far as I know this market, she’d make more money (bigger provision) if she sold me more expensive insurance. And she wouldn’t waste an extra hour.

On the other hand now I don’t consider anyone else to sell me car insurance in the future. She completely won me.

If you’re ready to deliver exceptional customer service you’ll win many long-term relationships like that. Don’t say about it – do it. Don’t consider your service as exceptional when you’re in common situation (then your service is common). You can really show you rock when something unexpected happens. Something like weird customer such as myself.

By the way if look for car insurance broker in Krakow I know a great person. Feel free to contact me for details.

Integration Events: One More Argument In People versus PM Techniques Discussion

2009-05-26T22:13:00.001+02:00

This weekend I was on integration even organized by my company. It was great. Period. I’ve seen a number of these events and almost all of them are done by the same schema. This one wasn’t different when it comes to a source schema but somehow it worked great.

Organization of the event definitely wasn’t the best I’ve seen. Budget, as far as I can guess, also wasn’t the biggest. So called attractions weren’t extraordinarily sophisticated. The place was nice but I’ve seen nicer. Why the event was so special then?

People. It’s all about people. Where there is chemistry between people you don’t have to excel in your organization and your processes don’t have to be top-notch. People will cover all small glitches and will give something more from themselves – a great atmosphere. This can’t really be organized.

On the other hand you can have a perfectly organized event in a great place with great attractions which cost you a fortune and everything can be barely, well, just a perfectly organized event which no one will remember about in a month. It leaves nothing but a faint sense of appreciation for organizer’s skills.

Now, how it maps to project management you ask. You can have a great product, perfectly organized project management process and still you can end up with lukewarm projects no one really cares about. Actually that’s what big players on consulting market do all the time. A missing ingredient is a passion. Your team can show passion working on a product in the same way as it can show passion when they entertain themselves during integration event.

This ingredient can’t be invited as a management decision. It’s all about people. They either are passionate about what they’re doing and you’re lucky or they aren’t and your project will be decent at best.

How about your people? Are they passionate?

Shortcomings of Test Cases

2009-05-21T18:17:00.000+02:00

I’ve already told you that writing test cases is worth the effort. What I haven’t stressed are shortcomings of test cases.

If you take time to prepare test cases you most likely do it for the reason and I guess not for “my manager will fire me if I don’t” one. You want to invite some organization to your testing and improve overall quality of the product at the end of the day. I don’t want to go deeper for motivations since it isn’t the point of this article.

The thing you do is preparing some scenarios up front, definitely before you actually start testing. Generally the earlier the better but either way test cases are before test execution, that’s for sure. Basically when you prepare test cases you imagine how you’d like the application to be tested and you write it down. Do this, verify that, expect something other and proceed to the next step.

Now what’s wrong with that?

1. You suck at predicting how your users would use the products. We all do. Applications are built by developers who don’t even try to imagine how users will interact with software. Then they’re tested by quality engineers who are also far away from average users. Then they’re deployed by people who actually talk with users but can’t influence application development in almost any way. The whole process is driven by product managers whose job is to think about general concepts, not detailed usage flows. Who cares about usage scenarios then? Well, pretty much no one.

2. Test cases are closed scenarios by definition. When designing test cases you don’t have “flow with your gut feeling” block at hand. You actually have to make it possible to verify thus limited to some specific path – one among hundreds or thousands. Which means you won’t go through the vast majority of cases yet you will decide whether a new feature works well or not.

3. It’s not possible to have a complete set of test cases. A typical method which takes only an integer as an argument can be called in possibly 2^32 different ways which is basically infinity. If you add that you may need to call another function as a prerequisite you end up with a number which blows my head up. And we’re talking only about a single function, not about whole application. Test case is always a dramatic simplification in terms of possible usage scenarios.

4. It’s easy to complete test cases and call it a day. Hey, after all test cases are for quality engineers, aren’t they? QA people should base their activities on test cases. Except they shouldn’t limit their work just to test cases. And you want it or not there’s always a bit of incentive to turn off your thinking and just follow the plan instead of going an extra mile. I’ve already said that a couple of times, but QA team is no place for follow-the-book people. Creativity is a key trait for QA engineers, yet we don’t live in an ideal world and you don’t have only the best and the most creative people in QA team, no matter what your company website says.

With all these shortcomings I still strongly advise you to write test cases. You may try to do them as precise as possible, or you may just use general flows leaving some autonomy for testers but either way it will pay off. Especially if you understand where test cases fall short and find a way to deal with that using other tools.

My Private Project: Incomplete Requirements

2009-05-15T17:30:00.000+02:00

This is another post from my private project series where I compare reality of house building and software development looking from project management perspective. This time it’ll be about requirements.

One could say requirements for house building project are pretty straightforward – two bathrooms, three bedrooms, one kitchen etc. The problem is these are coarse-grained requirements. At the beginning you don’t know about a lot (and I mean a lot) of fine-grained requirements which you become aware of during the process.

You don’t try to decide where exactly radiators would be placed or which switch will turn on which lamp and where exactly the lamp will be hanged. Actually you don’t need to know all these details at the moment you still have bare walls. That’s so agile by the way – coarse-grained requirements up front and setting up details only for nearest tasks.

Unfortunately way earlier than you’ll be designing how rooms will look like you have to make up your mind since plumber and electrician have to complete installations before you start plastering inside. Vendor, let’s take electrician for the example, is facing incomplete requirements. They want to know every detail of electric installation so they ask a project sponsor – you. The problem is you don’t really know since for you it’s too early to decide.

You end up not giving much detail to electrician and having random electric installation or making your decisions on the fly. Either way it’s definitely not a perfect design. You gave incomplete requirements and you, as a project sponsor, are the one who suffers.

How it is compares with our professional lives? Hidden and forgotten requirements are basically the same. Even in BDUF (Big Design Up Front) projects it is impossible to have all requirements included. The painful way we learn which requirement we forgot about is also similar. It’s usually vendor which comes to tell us, or rather ask us tough questions, about things which aren’t defined yet they should.

The main difference is in the way the issue is resolved. When building a house you don’t expect that builders would share your vision of the final product. You just give them specs and they ask you about anything which isn’t there. When building software it is different. Instead of specs you give a vendor something like a description of a vision of what product should look like. When after all it appears the product doesn’t fit to the vision because the vision was vague or it’s changed in the meantime the vendor is the one to blame for “failing to deliver business value” or something.

Maybe the problem lies within specs. With the design specs for the house even I can say which parts weren’t done according to the original design. Specs are pretty unambiguous. With software functional specification will never be all clear. The whole software thing is actually pretty darn ambiguous. Yet everyone expects we’ll somehow transfer our visions between our minds. It’s a bad luck we haven’t yet invented transfer method which is lossless.

Whole my private project series

What Is the Main Benefit of Writing Test Cases?

2009-05-13T18:03:00.000+02:00

Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value then?

Think about the comparison: test cases for application functionality are the same as unit tests for application code. Except of one thing: it is way harder to write good and complete list of test cases. You may safely assume that’s impossible. This means the main value of test cases isn’t in covering full application functionality because you simply won’t achieve that, no matter how hard you try.

Well, maybe it is a valuable tool for QA engineers? You know, they have some kind of walkthrough for testing sessions. Hm... show me quality engineers who prefer just to follow test cases instead of explore the application by themselves and I’ll tell who should be fired. Testing is such a creative task that there should be no place for follow-the-manual people in QA teams.

OK, test cases don’t ensure completeness of tests and don’t help QA people much. So? Show me the money, as one of my customer used to say. Where’s value?

The main benefit of test cases lies in the activity of writing them down. Or, to be more precise, in the process of thinking about them before they’re written down.

Test case is not much more than short scenario of application usage. Sometimes pretty weird scenario but still. Unfortunately we often forget about this perspective. We tend think in terms of code or requirements and forget about the very basic thing – no class in the code and no requirement alone makes any sense for the end-user.

Looking at application while being in end-user’s shoes benefits in two ways:

- You find black holes of your design which aren’t covered with user stories, or requirements

- You find usability issues since you see whole usage flow, not just a bunch of atomic functions

The main value of writing unit tests is actually within the writing part.

Sure Shot Method to Improve Quality of Your Estimates

2009-05-08T17:57:00.000+02:00

That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.

Split your tasks to small chunks.

If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.

Why it works?

• Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.

• Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.

• Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.

As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.

And yes, the only thing you need is some time.

What Can Project Manager Do For Developers?

2009-05-06T19:34:00.002+02:00

A project manager has a lot of relations with different people around. Stakeholders, managers, subcontractors, analysts, designers, quality engineers and a heck lot of other people. Oh, and don’t forget about developers. Actually relation between PM and developers usually is pretty special.

Developers often treat PM as The Source of All Evil. And to some point they’re right. It’s a project manager who brings more work. It’s a project manager who bugs everyone asking when they’re going to be done. It’s a project manager who brings all the bad news from customer. “We’ll do that other way since, well, the guy from marketing has changed his mind. And yes, I know we’re going to throw out a month of work. We’ll need to add these new features too. You know, client pays, client expects. Oh, and one more thing – UI design which was accepted two months ago is no good anymore, so we’re going to redo the whole thing. And we’re already late so we need to push little harder guys. C’mon, you’re great... Don’t look at me that way – I’m not trying to make your life miserable it’s just how this business looks like.” I think you get the point.

That’s the part of project management job and neither PM nor developers can change it. OK, now we know what PMs do to add more work for development team. But what should they do to make developers’ work a bit easier? Basically just one thing:

Get all the crap out of developers’ way.

Let them do what they do best – code. OK, they will redo several things as a customer makes their mind, but that’s still coding – something they should love to do. After all they’re redoing their code all the way without any external incentive and they’re all hot about that; they call it refactoring or something. There is however a list of things which can be, and should be, taken out of developers’ way.

Start with all the office politics. Filter it all out. Take all the hits on your chest. Bureaucracy is next on the list. Yes, we so often need to produce darn lot of paper. Do what you can to let your programmers forget about bureaucracy, which probably means you’re about to fill the papers. Be as technical as you can. If you don’t have other choice but to go bother developers asking them for things you don’t understand at least try to learn it so you don’t have to come back each time someone asks you similar question. Find people who will help them to set up what they need e.g. testing environment. Don’t overload them with stack of status reports which tell you what they’re doing every single minute. This time less is more.

Basically, be a helping hand for developers. Yes, not the other way around. They’re builders. The best you, as a project manager, can do is helping them in building great products. If they end up helping you in project management something is wrong.

Chaos Report 2009

2009-04-30T14:27:00.004+02:00

Standish Group has just released CHAOS Report 2009. News is spread pretty fast and there are many skeptic opinions about value of CHAOS Reports, including these which call the publication as useless.

Personally I consider the report as a valuable source. Not that I don’t see flaws of Standish Group publication, I just take it as every statistic, with proper distance, and I come into my own conclusions.

A few numbers revealed in press release show little difference from what we saw in CHAOS Report 2006:

• Only about one third of projects can be considered as success

• Less than a half projects are challenged (I always loved the term)

• More than 20% projects failed

I don’t really care much whether we dropped a few points in success rate or which nuances moved several projects from “challenged” to “failed” group. The main conclusion is the same and it isn’t very positive:

Nothing changes.

We still are poor at delivering projects. Yes, we are. Oh, yes we are. Yes... well, never mind. Hey, agilists, where is your silver bullet? Seems it doesn’t work. Sorry, couldn’t refrain myself.

Why it is so? I think the problem isn’t located in any specific, flawed project management methodology. I think everybody got used to it. Actually statistic customer expects that half of their projects will be challenged and only 3 out of 10 will succeed. And they’re cool about it. Oh, they will play their role of enraged client, that’s for sure. Then they’ll tell you to cut your next schedule in a half because last proposition isn’t acceptable. And guess what, there will be another challenged project to add to the statistic.

Another part of the picture is that vendors don’t care much either. I know only few teams which actually try to learn how to prepare reliable estiamtes which are prerequisite to deliver more or less on time and on budget. Most of schedules for software projects should be read as “our rough guess is that we’ll deliver it on 3rd quarter.”

What we learn from CHAOS Report then? These results are here to stay. Another three years won’t change things much. We’ll be adopting new trendy techniques and it’ll end up as always – in struggle.

A minority which is able to deliver what they promise will differentiate from the rest every now and then. Seems like a pretty good strategy for me.

Social Media versus Project Management and Software Development

2009-04-27T19:13:00.007+02:00

Everyone talks about social media. Social media this and social media that. No matter what you do you should use social media to build up your potential, speed up your growth and create new opportunities.

Project management or software development is no different here. As a project manager or a developer you should run a blog and read many others. Not only read though, you should comment often too. You should of course use the coolest tool these days – Twitter. Don’t forget about communities, yep, a number of them. And keep your profiles alive on all these social sites, starting from Facebook and finishing at LinkedIn. Oh, you should participate in different groups of professionals there as well. Now, you keep your finger on the pulse.

Let me ask one question: while exercising all these activities how do you find time to actually manage projects or to develop some code from time to time? “I don’t have private life” counts for the answer if you ask me, but I wouldn’t advise you to go that way.

I understand a trend to incorporate every new cool service which is out there to our professional lives but sometimes it starts to be counterproductive. People focus on “socializing” instead of getting things done. Mixing software development or project management with social media doesn’t have to be win-win because some guru said so.

OK, time for confession. I read blogs. I run one. You read it so it’d be hard to hide the fact anyway. I comment here and there from time to time. Heck, I even joined Twitter (follow me there). And yes, I still have time to work and my wife still hasn’t divorced me, which is a sign I cope quite well with the situation. However, except of keeping blogging frequency on typical level (at least a couple of posts weekly), every other activity is dropped whenever I don’t have enough free time.

What more, I could abandon (almost) all these routines with no real influence on my work quality. The only one I’d spare would be reading some stuff to keep learning new things.

Does all social media thing help my projects? Nope. Do I see any simple way to change it? Nope. At the moment twitter-like communication in projects is more making up a theory to ground usage of a tool than fulfilling a real gap in our everyday practices.

Now as I published this post, I’ll tweet about that and check interesting things people wrote on their blogs. Maybe I’ll even drop a comment somewhere. It won’t make my tomorrow work day even a bit easier though.

Which Project Manager Would You Hire?

2009-04-22T21:17:00.003+02:00

Meade Rubinstein started interesting discussion under my posting about great performances in failed projects. We came to a dilemma. Would you prefer to hire project manager with history of successful projects or rather someone with history of great management?

Meade tends to value more projects track record stressing we always find excuses for failure whenever we need it and comes with success factor as the primary and most important measure for project managers.

I, on the other hand, lean towards treating effort as more important than goal itself. I believe there are situations when even best PM won’t help and the only method to avoid scar on personal track record is to keep away from them. Avoiding risk isn’t an attribute PM should have, is it?

Consider you have two candidates. Jim succeeded in many past projects. He knows all the theory and pretty much practice. He gets thing done his way. Unfortunately you consider him as a kind of asshole and you’re afraid he can harm team chemistry. Jane fails more often. Maybe she’s a bit too mild. However she’s very competent and has a lot of experience from difficult projects. She led teams to achieve as much as possible, even when it still wasn’t enough.

Your choice. Jim or Jane? Why?

Great Performances in Failed Projects

2009-04-20T19:34:00.002+02:00

It’s always a difficult situation. The last project was late and I don’t mean a few days late. People did a very good job trying to rescue as much as they could but by the time you were in the half you knew they won’t make it on time. Then it comes to these difficult discussions.

- The project was late.
- But we couldn't make it on time even though we were fully engaged. You know it.
- You didn't tell me that at the beginning. Then I suppose you thought we'd make it.
- But it appeared to be different. We did everything by the book and it didn't work.
- The result is late. I can't judge the effort with complete disconnection from the result.

How to judge a project manager? Final effect was below expectations. Commitment on the other hand went way above expected level. Reasons for failure can be objectively justified. Or can’t they?

Something went completely wrong. Maybe initial estimates were totally screwed, maybe it was unexpected issue which couldn’t be predicted, or maybe we didn’t have enough information about the way customer would act during implementation. Who should take responsibility?

It is said that while success has many fathers failure is an orphan. There’s no easy answer, yet manager has to come with one.

I tend to weigh more how people acted (their commitment and effort) than result (late delivery) but I treat them as interconnected measures. In other words great performer from failed project will get better feedback than underperformer from stunning-success-project. Here’s why:

• I prefer to have committed team even when they don’t know yet how to deal well with the task. They’ll learn and outgrow average teams which already know how to do the job.

• I wouldn’t like to encourage hyena-approach, when below-average performers try to join (already) successful projects. It harms team chemistry.

• If there’s a failure I (as a manager) am responsible for it in the first place. If I did my job well me team would probably be closer to success.

• Punishing for failure makes people play safe. Team will care more about keeping status quo than trying to improve things around.

• Lack of appreciation for extraordinary commitment kills any future engagement. If I tried hard and no one saw it I won’t do that another time.

When Unit Testing Doesn’t Work

2009-04-16T16:36:00.006+02:00

Unit testing is such a nice idea. Developers create tests as they develop working software. Then they (tests, not developers) are executed during every build and it’s verified whether something hasn’t been broken over the way.

Unfortunately unit tests very often doesn’t work well even when team formally boast they employ this practice. Why?

1. Unit testing can’t be enforced. Yes, yes, I have heard about tools which measure code coverage. A problem is they tell you whether your code is covered but they don’t tell you with what. It can be covered with quality tests but odds are it is covered with a lot of crap generated just for the sake of achieving target code coverage. Remember you get what you measure.

2. Writing unit tests is easy – maintaining them is a hard part. Consider you have your code and your tests perfectly working. Now you change something which breaks several tests. Is that a flaw in the code? Or maybe it was done on purpose and now you have to rethink and rewrite all broken tests. Heck lot work to do.

3. Tests should be added all the time. When you find a bug which wasn’t caught by tests you already have you should add one which will do it in the future. And yes, that means more work on crappy maintenance tasks which is neither funny nor developing.

4. It takes so long to run all unit tests. Sometimes tests are switched off because build process takes too long and they don’t have to be run each time, right? Well, wrong. They have to.

5. Good unit test checks border condition while easy-to-write unit test exploits optimistic scenario. It’s pretty easy to write unit tests not using your mind at all. 2 plus 2 should be 4. Task completed. Case closed. How about using 0 or negative numbers or floats? Forget about them – too much work.

6. Writing unit tests is boring. That’s not amusing or challenging algorithmic problem. That’s not cool hacking trick which you can show off with in front of your geeky friends. That’s not a new technology which gets a lot of buzz. It’s boring. People don’t like boring things. People tend to skip them.

A key thing to have unit testing implemented well as a practice is right approach of developers. Unfortunately it can’t be trained. These lads and gals either believe unit testing helps them to create good software and they do their best to develop high quality unit tests or they just cover the app with some crap just to get proper code coverage result and pull the problem out of their ass.

If you’re going to use unit test better be sure your people are the former. Other way around it’s not worth the effort.

Why Slow Start in Project is Such a Great Idea

2009-04-10T23:14:00.004+02:00

We’ve just started a new project. We are at the very beginning and we still don’t work under pressure of time. And that’s great. Such slow start is a chance. A chance to set things up as you would like them to see in ideal world.

We use this chance to:

• Choose and verify tools used during development. Continuous build, unit testing, static code analysis, coding standards – all this things which should be on place but so often there isn’t enough time or you have to throw everything away because of some emergency. And if you try to do it in already settled environment it’s such a painful and long process.

• Design properly. Have you been in a situation when you just do your wild-ass guesses (aka rough early estimates) and suddenly you have to start coding because you’re a month behind a schedule before even a contract was signed? It is said that testing is the first place where you (unwisely) cut schedules. Well, designing holds a strong second position.

• Find time to discuss requirements. Is all clear? Yes? Good. Write it down. Go at least one level deeper to get more details. Another time write it down. Now, get people read it and understand it. Are there any questions? Of course there are. Congratulations, you’ve just eliminated some issues which would appear later and would be way more painful.

• Adjust project management techniques. Ensure you gather all the data which will point how much you miss initial estimates. Set workflow for work items which won’t be a pain in the ass for developers. Think what people pointed as problems during last post mortem session – do you always find time to use this knowledge to improve your projects?

Basically all these things are just simple ways to avoid or limit technical debt. If you start slow it’s much easier to set them up properly which soon will return in terms of team general productivity. Of course that does mean additional work if you compare it to impossible-to-meet ideal world schedule where everyone produces best of breed results with highest possible performance.

The reality is that projects with technical debt starts producing visible results faster but they soon lost their advantage and over time are more costly. Starting a project slow gives you an excuse to do a good job in this area. You can need one for your bosses and you can need one for yourself.

Developers Should Work on Crappy Machines

2009-04-07T22:14:00.002+02:00

At the moment my Firefox uses more than 250MB of RAM. Today’s peak was at 470MB. Simultaneously Internet Explorer (we use Share Point and Share Point in Firefox sucks) eats more than 150MB and with each tab I open it grabs another 25MB.

What the hell? What these applications do with all the memory? Some kind of temporary public distributed storage where they compute how to rule the world or something?

If I restart both browsers and they reopen all tabs Firefox needs less than 120MB and Internet Explorer needs less than 100MB of RAM. What did they use the rest for before restart? I guess I already asked but what the hell?

Believe me browsers aren’t only applications which suck in terms of memory usage. TweetDeck? 90MB reserved instantly after starting. And that’s for an application which pretty much works as RSS reader. MS Outlook? 80MB to 100MB after few whiles. Live Messenger? 60MB just after start just to log me in and display contact list. Wow. Or should I ask what the hell?

Developers of each of these applications don’t give a damn about memory they use on client machines. They allocate loads of memory whether they need it or not. Thus they should be punished.

As a punishment they should work on crappy machines in terms of available RAM (and arguably processor power). This way they would suffer each time they had to check anything in working application. Developers are pretty smart beast. They’d get the thing.

“So slow. Oh so slow. Why a swap file is used so extensively? Hm, my machine run out of RAM, that’s why. Maybe the app is allocating too much memory? Maybe I should do some refactoring to show them what The Real Hacker can do when he’s pissed off because of his too slow PC...”

I don’t advise developers should get 1024x576 displays which would make minimal screen resolutions fine in virtually every application. I’m not sadist. Not to that level at least. Let them have their fancy 22’ screens (or whatever they get these days). However exchanging their machines to some old crap would make users’ world nicer since developers would share our pain in the ass. It’s so humane, isn’t it?

When they learn to care about memory usage they can get back their super-duper PCs back which is a carrot complementary for a stick.

Minimal Resolution Counter Strikes

2009-04-06T19:44:00.004+02:00

I installed Visual Studio recently. Not that I plan to get back to programming but I needed a client for Team Foundation Server and web client unfortunately doesn’t support all needed functions.

I must admit guys from Visual Studio check whether display resolution is suitable to for the application. A plus for them. During installation I got the message:

“Visual Studio 2008 is designed for a minimum resolution of 800 x 600. Although Visual Studio operates at a lower resolution, you should set your display resolution to 800 x 600 before running Setup.”

800 x 600? Um, wrong. Rather 1024 x 576. Can’t set it the way you want. The funny thing is they check display resolution but they come up with wrong conclusions. A minus.

Anyway so far I see no problem with not sufficient vertical resolution while working with Visual Studio. I guess the only potential problem is within horizontal resolution since there would appear horizontal scrollbar (which always sucks) or something. A big plus.

Overall my impression is positive. Actually Microsoft (except of Live Messenger) does pretty good job when it comes to minimal application resolution.