Long Life Old Programming Languages

SDTimes brings a nice story about not teaching programming languages like LISP anymore. That reminded me about renaissance of programmers knowing ancient languages like COBOL when y2k bug was coming and there were still a lot of working software written in those languages. Suddenly it appeared it’s hard to find a COBOL programmer and being the one can be quite worthy.

It still looks like a good idea for me to know some old-school technologies and become a specialist in that area of knowledge. I consider C/C++ as dying language. Yes, students are still taught C++ and yes, it’s still easy to find software written in C++, but developers generally prefer more modern languages (Java, C#) or those trendy ones (Ruby on Rails, Python). Finding a developer who wants to write in C++ is harder and harder over time, yet market demands significant number of them.

The easy reasoning here is: still much code written in the technology, few people willing to use it, should be worth to be a specialist in the area. I think it’s easier to become highly-paid specialist when you choose less popular technologies than it is with the mainstream ones. Anyway, developers somehow follow the trends and rather rarely take into consideration above point of view.

404 Error Handling

If you have a website it will happen. Someone will make a typo in the address. You will change pages addresses and old one will become outdated. People will just try to enter the page which isn’t there.

Will they see that?


Or maybe you’ve made some effort to keep them stick to your website for at least a bit longer. You ccould try to make the 404-page a starting point like on ProBlogger. Or you could redirect those requests on simple error page and than to main page like we do in on Overto site (sorry for Polish language, but it is Polish site). There’s an option to make a simple redirection to main page with no message in the middle. OK, there are heckuva lot of options and every one is better than leaving simple “no page, bagger off” message. Of course as far as you don’t want your users to bagger off.

Software Development and Project Management

During last weeks there was active discussion around under the flag “Agile project management is not about project management but about software development.” I think the thread was started by Glen Alleman. Among interesting comments you can find his follow-up on the subject and two cents from Bas de Baar.

To make the long story short: I agree with Glen and Bas that things usually covered with the name “Agile Project Management” are telling more about managing software development which is usually important but not the one and only part of project management. By the way we tend to see project management as an area exploited in IT only while it is widely used in others areas of our lives (building industry is a great example here) which haven’t much to deal with computers and all those software stuff.

Yes, project management is usually much wider process than software development and definitely more complex. But why the heck the discussion mentioned above was limited to agile methods? The difference is the same no matter which methodologies you use to develop your software and to deliver your projects. Hey, replace the word “agile” with “waterfall” or “iterative” and all the arguments still work. That doesn’t really matter if you’re agile or not, software development and project management will usually be two different things.

Take It or Leave It

Robert McIlree has commented my recent post about agile methods. I believe one thing from the comment is worth mentioning. Robert says:

“I will take issue that Agile methods are no different from a take-it-or-leave-it standpoint as opposed to traditional process-oriented methods.”

There are two general approaches to implementation of any methodology in software development. One says you should treat the chosen method as a bible and adjust your organization to work exactly like it’s written in the books. Another says: here’s the thing, you can take whatever you want and leave whatever you don’t want but remember every decision brings its consequences.

While almost no one would admin to choose the former approach it’s quite often. Ask people why they don’t like Prince-2.

"- It is sooo heavy and formal.

- Why don’t you cut unneeded things off then?

- Can I??? They haven’t told me that."

Personally I’m on the other end of spectrum. I believe you can use take-it-or-leave-it approach with virtually every software development methodology. Unlike Robert I believe that process-oriented methods are no different here. Even there you can decide to change only several areas and leave the rest unchanged if it works well for you. You just need to know what you resign from and why.

Agile Methods Applied

In his last blogpost Bob McIlree shares his thoughts after a couple of agile classes he made recently. The whole post is worth reading but my attention was drawn to one general observation – among experienced project managers distance to agile methods is significant and confidence in their effectiveness lays two feet below the ground level.

I was never an agile junkie, I rather prefer agile methods described by Steve Yegge. By the way I guess that’s something which can earn me an excommunication from some Agile Conservatives. What more, I haven’t treated any software development methodology as a religion. Yes, you’ll hear about evangelists, bibles etc, but that doesn’t work like a religion (you just believe and it works). You can easily find environments where agile methods would suit well, but there are some where even implementing a cycle model would end up like a tsunami in a seaside village. That’s one thing which lies behind fear of agile methods. Another is of course lack of will to move from safe and well-known environment. I’m not surprised looking at skeptics among PMs. And to be honest I really don’t think that Bob’s classes will help to overcome distance to anything other what they know.

There’s only one way here – change your environment. Afraid of water? Want to learn swim? Training classes in a classroom won’t help you much. I’d rather try to change environment into more waterish one, like pool or something. I moved to my current firm after several years of working with MSF. My naive point of view was that I’d implement methods I knew and it would work perfectly like during the good old days. I couldn’t be more wrong. Different projects, different people, different teams, different customers, different organization, everything so damn different. Why the heck the process should be the same?

The same rule applies to agile methods. Take from them what you believe can work in that particular environment and leave what you think is useless. There’s none universal and perfect methodology and, excuse my bold statement, agile methods aren’t any different here. In other case we all would use them and I’d be unemployed. My answer for quite often heard “I’m a big fan of agile methods” is “And I’m a big fan of common sense.”

Which Features Are Important?

Several days ago I had a quite insightful discussion about software functionality and usability. Among others we went through Google Spreadsheets and features which should be on the top priorities in a team working on that project.

Maybe I’m a bit controversial here, but I think Google Docs are in the point where there’s a lot of toilsome and dull work ahead. The thing which should be improved now is generally an editing area. I don’t say it doesn’t work. On the very basic level it works well. However, quite a few of us use the very basic features only. When asked, no one would really answer consciously which “advanced editing features” he uses, but after a couple of hours of playing with the application most of us will find a series of small but annoying flaws. These are non-standard features we use.

Highlight B2 and C5 cells. Only those two. Mark a group of numbers to quickly check their sum on a status bar. Change text or background color of cells with only one click. Mark several columns with shift+left-click. Make some simple formula using keyboard, e.g. type “=sum(“ and move to cells you want to sum using arrows. Doesn’t work.

Yawn. Boring. Nothing about on-line collaboration. Nothing about Google Gears (although I believe that’s another extremely important area). Nothing about adding advanced cool features like pivot table. But all that boring work is something what disheartens users when it isn’t done properly. Typical user who tries out Google Spreadsheet is the one who is familiar with Microsoft Office. The one who is familiar with ways she uses Microsoft Office, to be exact. As far as she doesn’t find similar (and working) paths in new spreadsheet she won’t be happy with it. And she won’t stick with it as a consequence.

Yes, when you’re able to keep the user and show him your unique features (collaboration in that case) and make him thinking about them as key functionalities – you’ve won. Unfortunately in most cases you won’t reach that point because few stages earlier the user becomes annoyed with the new software and goes back to old, well-known Microsoft Office telling all his friends: “Oh, that was cool, but sooo immature.”

By the way, similar problem we face in Overto. After first stage of rapid development we have on one hand a bunch of great ideas how to expand the service with new functionalities, but on the other there’s a lot of work to do within the basics: availability, performance and usability. With heavy heart I choose the latter.

Teaching Project Management Basics

After a conference we were sitting in the pub pouring beer. As the company was quite big and contained mostly developers, our subjects quickly went into area of a software lifecycle. I was talking with a couple of guys with a year or two of professional experience and barely had gone out of the university. They were working in quite a big team developing an enterprise-level solution. I was a bit surprised with several project/program management decisions made in their team, which sounded like asking for failure. No one had objected.

Sure, there definitely was a problem with project management in their team, but lack of protests was a food for thought for me. After a while I came to question.

“Hey, has anyone taught you project management at the university?”

I couldn’t believe. I know the project management is quite a wide and complex field, but in software development world it’s so common that at least teaching basics should be obvious.

Wait, wait, wait. The question was wrong. I played I-am-the-guru guy but was it fair? Should I criticize their university? I corrected the question.

“Hey, has anyone taught me project management at the university?”

Nope. Not at all. I was lucky with my first job, because I landed in quite well-organized team using MSF to organize software development process. I was lucky with my first bosses, who were aware of importance of project management and had decent knowledge about the subject. I was lucky to see my first team (and product) growth and constant improvements in organization. I learnt all the basics of project management because I had good teachers in my first job. My companions landed it a software conglomerate in a team with rather weak leaders and rather poor organization. How could they learn project management?

As I talk with graduates or undergraduates on different occasions I’m still surprised why students of computer science aren’t taught even basics of project management. In vast majority of cases they start the first job with attitude to software development which I call “student’s projects.” Student’s project is the one which is abandoned when it (almost) works in a couple of scenarios. It’s abandoned exactly a moment after a grade is granted. When you’re lucky it’s 90% complete, what means I would implement it in a production environment only if longed serious trouble. The student’s project usually is much more like a prototype than like a product.

Any software vendor I know expects quite different level of quality. The reason is simple – there aren’t many customers, who are willing to pay money for prototypes. So no matter how their development teams are organized, they need to fill remaining 10% of software development cycle. And that’s exactly the place where basics of project management are essentials.

That’s why I believe universities harm their students focusing on development skills, design and architectures only and leaving areas like project management untouched. Even now when hackers get a lot of buzz and money, they are usually the ones who don’t focus on hacking only, but are also able to finish their products.

Before I’m trodden into the ground with opinions about great universities all over the world which doesn’t suit to above picture I explain: I graduated mere single university, and I had contact with students and graduates from another few (almost) all from Poland. My thoughts are based mostly on opinions about them, although commonness of described issues brought me to fearless generalization on the subject.

Solving Problems with Bug Trackers

Ian Landsman with his quick idea about bug tracking triggered a little discussion about the subject. Why we have a problem with tons of bugs/feature stored in bug trackers? Why ideas like throwing out a bug tracker appears? Why we’re advised to leave feature requests tracking at all?

I think the problem lies not within bad, bad bug trackers which become bins storing everything. I think the problem lays in the way we use bug trackers. If your bugs database is cluttered it’s most likely not the fault of application itself.

Why bug trackers become cluttered?

• Organization. You need versions, application modules, priorities, submission states etc. You need people responsible for every bug or feature request. Although it looks fairly easy from the perspective of a single bug, it’s much tougher when you look at all that mess after 2 years for 3 applications (4 versions and 6 modules each) with staff rotation and strategic reorganization introduced by the board because it’s more than a year since the last one. The rules should be clear for everyone. When there are too many submissions with “critical” priority it’s either people overusing it or you have a problem with your product, not the bug tracker. When single person has more bugs that he can grasp it means that they’re either poorly organized or you have a problem with your product, not the bug tracker. When you submit issues only for the sake of submitting them not planning to do anything with them it’s either problem with people’s responsibility or (you won’t guess) you have a problem with your product.

• Cleaning. The bigger the issues database is the more you need to clean it once in a while. Review feature requests which are attributed to future versions in case they’re already done or become obsolete. Yes, it is an additional effort, but you don’t leave cleaning your house only because it’s additional effort. If you do, you shouldn’t at least moan that the house is a bit messy. Another thing here is moving things you know you won’t do in the very version to future ones as soon as you can. Leaving them on developers’ dashboards won’t help you much anyway. Adjusting original priorities is also the part of the work here.

I think that well-organized suitable bug tracker isn’t an option. It’s a must-have. And of course a suitable bug tracker can mean different application depending on a product, team etc. For one of my projects free version of simple 16bugs works well. On the other hand I know teams that use fully-blown Visual Studio Team System installation, including issues tracking of course. One of the best tracking applications I’ve seen was developed in-house – I wouldn’t recommend using it in any other company but for that organization it was like a tailor-made glove. It suited perfectly. On the different hand it would probably look and work lousy. And it would have brought another load of mess.

I’m far from blaming applications for problems with bug tracking. I’m even further from redevelopment of a way we manage bugs and feature request. I prefer to start with doing it right in the old-fashioned way, like a grandma taught us.

Internationalization Trick

Few days ago Joel Spolsky announced a launch of German version of FogBugz. I guess the reason was to spread the word but he wrote one very important thing about internationalizing applications:

“To ensure that every string is localizable, our developers translate everything to Pig Latin first before handing it off to the German translators.”

I think it’s worth underlining. It’s the old trick to change every string in the application to something which is understandable by translators and yet it allows differentiating easily translated texts from not translated ones. One method is Pig Latin (I guess Fog Creek developers had a lot of fun while preparing the Pig Latin version). Another is adding, on the beginning of every text, a character which isn’t used in strings presented in the app (probably something from the latter half of ASCII table).

Thanks to this, you won’t accidentally leave words which has a meaning in both languages unchanged. You can also test, before starting translation process if every single piece of text is extracted form code and put in some kind of external resource. Every prompt which isn’t Pig-Latined or doesn’t have this little trashy thing on the beginning is probably a bug.

When talking about German, there’s another issue – German words are statistically longer than English ones. This can be an issue when you have fixed position of controls on windows. To fix the issue without changing all the windows you can use different font – more narrow one.

Buying Software Components

Ian Landsman shares his story about buying software components. On the very beginning he tried to write it on his own. I can’t say I’d support the idea – Userscape (Ian's company) focus is to provide helpdesk software not to be UI components programmer. What more, being a micro-ISV, it would be almost impossible for him to support and develop those components in the future. I believe that narrow focus brings you closer to a success and in a case of obtaining software components it means you should often consider buying them.

Another episode in Ian’s story is buying a cheap menu and ending up with some issues with it. Finally he bought another one, few times more expensive, and it looks like he’s satisfied at least. As a conclusion Ian states that “being cheap is only a path to heartache and support requests.”

I can’t say I fully agree on that one. I think the main issue here was not the price, but functionality of bought component. I guess the last menu wouldn’t be worse only because someone cut its price. When we were choosing some UI components to buy we’d made some analysis first, covering different sources from free up to unreasonably expensive ones. And we chose an option which was priced fairly and had more than satisfying range of features. Yes, we spent some time on that, but it paid off. Even internal report with analysis appeared to be useful months later when we had justified some investment.

Don’t be cheap, but remember the price is only one of ingredients. Sometimes the most important one, sometimes not.

Getting Used to Features

People like features. People look at features when they’re choosing the software. People get used to features. Then, they’re not features any more – they’re obvious functionalities.

Vendors like new features. Vendors sell their software showing their new features. Vendors get used to features. Then they’re not features any more – they’re just part of legacy code. And occasionally they’re removed or changed.

I’ve once upgraded my Firefox from version 1.5 to 2.0. And then settings connected with a way the links are opened have changed. They’ve taken away my feature. It’s the easy case because I could change browser options, although it’s been quite ambiguous. However I’d gotten used to the “feature” so I wouldn’t even ask if my new browser can work the same way.

Few days ago I got a new notebook. On the old one I had Clear Type turned on. I wasn’t aware how I got used to it unless I saw crappy fonts on the new machine. That’s another easy case because I could quickly install Clear Type Power Toy without even going through Windows configuration. However in both cases I was confused. Hey, wasn’t that already on the board?

Things get harder when you develop your software for a bunch of companies and hundreds of users. You quickly pass the border when you can’t know every scenario the users will follow. You can quite safely assume that at least several of people adopted every single feature of the application, no matter how crappy they can be. They came to like features. They got used to features. They don’t consider them as features any more.

Here’s the trap. Now, you’re a hostage. You can’t change them and even improve them because you’ll piss off you users than. And, let me guess, you don’t want to piss off your users, do you?

That’s why you have to remember about boring check list every time you prepare upgrade for your application:

• Configurability. When changing the way some process works, add an option in configuration and let the user choose. It’s also a good resolution when you face two groups of users who want the function to work in two mutually exclusive ways. One time we even wanted to add an option where the user could choose how the feature should work: either “ambiguous” or “wrongly”.

• Defaults. OK, you’ve added dozens of settings in your configuration window. Congratulations. Now, all defaults are set in the way that will show all new features, right? Wrong! It’s the perfect way to take away functionalities people got used to. With default configuration the new version should work in the way the old one would, at least in areas which were altered by the upgrade. You have to find another way to show off with your new stuff.

• Basics. Things like navigation, especially my favorite keyboard navigation, main functionalities etc. I wouldn’t mention them if I haven’t seen companies violating them.

• Inform and help. When you don’t have a choice or you consciously decide to change old features being aware of consequences, try at least to reduce users’ frustration. Inform them which features are being changed. Help with adjusting the application to work like it used to. If you can ask them before the change if it’s OK to implement planned changes. We’ve done that once and at least it was a kind of justification for making a change we had to make because of architectural reasons.

That’s of course just elementary, but it’ll help you current users to feel familiar with the new version. You don’t have to follow, just ask yourself if you do care about that.

Good Enough

My friend asked me to give an opinion about design of application his company had developed. I took a glimpse on their technical presentation with a lot of screenshots. I must admit my attitude was very positive, whole thing looked professionally. That’s what I told my friend. His answer was a bit surprising as he said he would have worked more on UI design. On the beta stage? It was really good enough. Or even better enough.

The discussion brought me to think about good enough paradigm in software business. One side believes that if software is good enough the job is done. Another wants to polish all the details until they bring their software into perfection. Although I haven’t seen any statistics about that I believe the former group is more numerous one.

Software constantly conquers new areas of our life including those where there’s hardly place for good enough believers. Hospitals, planes, cars or military areas. I guess you wouldn’t be happy if your good enough software managing your car brakes crashed. Yet still most software which is developed is not mission-critical products. It just sends e-mails, creates documents, pass information, manage some content, store some data etc. There’s a choice between good enough and close to perfection.

Personally, I’m a good enough guy. I have just one point here. Costs. Imagine a theoretical scale of perfection of software ranging from 0% to 100%. When you start your development you’re in 0% when you finish you’re somewhere in upper half of the scale. On the beginning improvements are easy. You invite first test UI which looks like it was designed by blind monkey. Then you have first iteration of target UI. It’s a huge improvement, probably a couple of dozens percents on the scale. However, when you’ve already made several iterations with UI and it looks decent the next would be probably making extensive usability testing. It’ll take much more effort than the first steps. Results will be probably much less significant. Few percent if you’re lucky. Next step? Maybe user feedback? You employ a number of people, who deal with all e-mails and phones from users, than trying to find a schema in all that mess, then verifying if accidentally some requests are not exactly opposite to others etc. More effort. More money. Results limited. Maybe another percent earned on the scale.

The example says about UI, but the rule is general. First performance optimizations will be fast and effective, unless you do them randomly. After some successes they’ll become harder and more costly. On the beginning of stabilization you’ll deal with big numbers of issues vastly improving stability of software. On the end the whole deployment will wait for a single bug fix. Of course that’s not a paradigm – there’re exceptions. Sometimes you can find some easy improvements even when you’re high on the scale, but it shouldn’t happen very often.

That’s why I’m a “good enough” believer. I don’t refuse to make small improvements, even when users can live without them. They’re welcome as far as they’re cheap. Great example was described by Basecamp team. Those changes are close to border separating good enough from better (hard to say on which side they are), but they were quick and cheap. And I guess the more important improvements were done earlier. If the changes were significantly more expensive I think 37signals would leave it as it was.

I believe that unless you have much time and money to spend you shouldn’t chase the ideal. There’re more important things to do.

Context Switching

Joel Spolsky writes about context switching during development cycle. While he agrees that for developers switching costs much, he reminds that costs of denial to switch the context should also be considered.

I can say I fully agree with Joel. Sure, if there is a possibility to avoid often changes of tasks and priorities, you should go for that. Unfortunately, quite often it’s just not possible. It mainly depends on relation between a vendor and a customer. When the vendor is much bigger than the customer it’s easier to refuse to switch the context to bug-fixing. I don’t say if it’s wrong or right; it’s just easier. However, if the vendor is a small company delivering their solutions to one, much bigger, customer refusing to switch the context is not an option.

It’s always painful for me when I come to one of our developers telling him to leave whatever he’s actually doing and take care of support issue or another prior task. I know we’re wasting time then, but still I’m aware of cost of refusing to switch the context. I can count several most important customers for my company this year, including one which always orders some functional changes on day before yesterday. Without those few customers it would be hard to imagine my company still living by now. Can we reject them if they need our help? Can we reject because we don’t want our developers to switch context? Can we?

Sometimes I hear those who say that you should never do context switching when it comes to development work. I’d love to see them in a couple of situation I experienced. Those bad weeks, when everything goes wrong, one emergency situation appears just after another and you’re facing the risk of loosing contracts (and of course money) several times per day. I think it would be hm... quite an instructive view.

Top 6 Problems with Risk Management

When you try to implement a methodology or invite a habit in your organization it won’t ever go without any problems. People don’t like to change, albeit their adaptation skills are high. Someone has to overcome the resistance and make whole thing working. He needs to find out what exactly doesn’t work and why. MSF is no different here.

One of hardest parts of MSF to implement was risk management. It’s funny because when you read about that it looks so reasonable and it all makes sense. We unconsciously manage risks in our lives whole time. Unfortunately, people’s attitude changes when it comes to a bit more formal process, which involves regular participation. Here are some typical issues with risk management. It’s based on MSF implementation example, but case is general.

1. That’s too general – I don’t see how it can work. That’s one problem with defining a risk: if it’s too general, e.g. “new version will be released late” it says nothing about real problem – potential reason why there can be a slip. Lead developer will be sick. Our last tester will change a job. Program manager is taking holidays during last two weeks of timeline. A reason should be named, not a result. And remember many reasons leads to the same result, so in this case naming a reason will bring more detailed risk.

2. That’s too detailed – I don’t understand a problem. That’s another problem with defining a risk: if it’s too detailed, e.g. “problems with multithreading in new API function will result in overrunning code complete milestone”, no one understands it. This risk is probably understandable by two or three developers actually using the function. For the rest of the team there will be a bigger impact on project when coffee is over. They don’t understand the risk and that’s why they won’t rate it high, so you can spare some time with not adding it to the list. Either make it understandable or throw it away.

3. Where’s the avoidance plan? That’s the hardest way of inventing a risk. Usually it’s easy to name the threat and rather not difficult to find emergency plan. But when you don’t equip your risk with good avoidance plan it’s almost worthless. OK, we can be late with the project, but what to do to ship on time? The answer can’t be just: “work harder,” it should be something different from things you’d do if there were no risk. Recruit someone, plan some bonuses for working overtime, switch some tasks between people, negotiate deadlines with customer, do something new. Of course sometimes no matter how hard you try you won’t come with anything reasonable here. Then you just accept the risk is going to materialize – you aren’t shipping on the end of the month. There’s nothing more to do. Shit happens.

4. I don’t see any change. OK we have our nicely crafted risks, we vote for them and discuss them on weekly basis, but where’s the difference? In the top 5 list there’s always the same set of risks, the same set of people responsible for them and the same things told. “This week nothing changed.” If really nothing changed person responsible for the risk should be ashamed, but usually something changed but it’s not reported because it doesn’t seem important. “Most of planned tests in accounting module were done, number of bugs increased, but we finally closed the tricky issue with deadlocks. In my opinion risk still stands high, even a bit higher as we’re a week closer to the deadline, but we’re moving forward.” Do you see a change now? There can be another reason – when often nothing changes and it doesn’t need to be the problem with people, it’s possible that you evaluate risks too often. I don’t say that weekly basis will work for every project.

5. Hey, that’s another thing I have to do. That’s obvious. Evaluating risks takes several minutes per week, but still it’s another thing to do. No one wants more bureaucratic work. Unless people believe that it really works it’ll always be something they do because they have to.

6. I don’t believe in that. That’s the most important and hardest to resolve issue. When you invite risk management process it doesn’t work perfectly from the very beginning. I’d even risk a statement that risk management on the very beginning doesn’t work at all. What more, even when it starts working, results are usually seen from management level – most of the team doesn’t see a difference even if you’ve ruled out an overrunning the deadline risk. After some time it becomes another duty which has to be done but gives nothing in exchange. You can’t tell the team to believe in the process. They have to see it works. Personally I started to believe in risk management after more than a year of participating. We ruled out two top risks only because we were working on them during whole development cycle and that was because they were topping during risk management sessions. When something like that happens show it to the team: “Look, after first sessions we feared this and that and when we were finishing a version do anyone even remember that?”

The key thing is confidence that risk management works. If you can convince the team that it’s helpful you’re more than halfway home. The rest can be and will be altered during risk management sessions. The hardest thing is improvement in people’s confidence.

MSF Basics: Process Model

MSF process model is divided to repetitive cycles. Each cycle is divided to five phases: envisioning, planning, development, stabilizing and deploying. Authors of MSF say it’s the best of two worlds – they took phases from a waterfall model and cycles from a spiral model, but it’s quite intuitive. Actually whole world uses versions and they have a kind of design, development and testing stages.

There are some principles connected with MSF phases:

• Although they’re lined with particular order (yes, that does make sense) one can overlap on another. Generally you start next phase as soon as possible. You don’t wait to finish coding to start tests. As soon as there is some (rather) complete code to test you can begin stabilization of a project.

• The first phase of another cycle can overlap with the last phase of previous cycle, so whole cycles can overlap also. No need to wait for finishing implementation when you envision another version.

• Every phase finishes with a milestone. It’s something that is yelling “hey, our part is finished!” Usually you already have another phase launched, so no place to boredom here.

• During every phase there are different leading roles. The leading role is the one which takes the responsibility for achieving the milestone, which finishes the phase. The leading role usually is the busiest one.

The model isn’t something hi-tech - it’s really intuitive when you look on the whole. OK, I think it’s time to briefly describe phases.



• Envisioning. That’s the phase when all decision-makers agrees on what they really want to do. Yes, the whole team should participate telling what they thing it should be done. Then of course a lot of discussions happen. A goal is to define which features are essential (and will be done for sure), which are important but not essential (and will be done if time allows) and which are not important (and won’t be done in this version). Consensus-driven document with those three groups agreed by the team (after long fierce fights) is a vision statement. That’s the milestone for this phase. Leaders in discussions are product and program managers.

• Planning. Here the work from previous phase is taken further. All detailed cost estimates, which has been taken basing on experience, are counted now. Vision statement becomes a list of tasks, to-dos etc. It materializes. Program manager leads that phase. It finishes with project/development plan.

• Development. You already know what (vision) and how (project plan) things should be done. Now it’s time for get them done. It’s the developers’ time. The time when your programmers get hard time (with reaching deadlines) but also have fun with creating things. The milestone here is something called “code complete”. It’s the moment when everything should work correctly (“should” is clue word here). OK, at least every essential requirement should be covered.

• Stabilizing. Time of testers. Time of malicious people (it’s the positive adjective in that case). Now you verify how well programmers have done their work and you constantly increase project’s quality (but not project’s functionality – it shouldn’t be enhanced now). Of course the goal is to have zero-bug version, so testers test, developers resolve issues, testers verifies if issues have been resolved indeed, managers look at bugs counter and they realize they did some mistakes during envisioning phase...

• Deployment. During deployment you need to deliver your fantastic zero-bug golden release to the customer. Everyone is content with his work well done. OK, almost everyone. Release managers earn their salaries now. Depending on size of the system some of senior developers can be involved too. The work is finished when the solution is successfully delivered to the customer. By this time you should have already started vision phase of another iteration.

And the cycle repeats. Till the end of the days...

Related articles:
Whole MSF Basics series

PS. I'll be on vacations in Croatia during next week so rather nothing new will appear here then.

MSF Basics: Team Roles

This is another article from MSF Basics series. This time I’ll describe roles in MSF team. In MSF 3.0/3.1 there are 6 of them, version 4.0 adds one more.

The Team

Nice and lofty rule in MSF says that there’s a team of peers and all decisions should be made by achieving consensus. That means an organizational structure should be left behind and the whole team should be treated on equal terms. You should try hard to organize people this way, but probably you won’t reach the ideal. Don’t worry – being close is also counted. Thing you should remember here is that everyone should be able to contribute in decision making. At least in making those decisions, which can be made collectively.

It’s funny that if you reached the ideal you wouldn’t be able to make most decisions because if they have to be made unanimously there’s always someone who doesn’t agree (I believe there has to be a Murphy’s Law for that). Solution is to have the one more equal among all equals. It’s the person who is in charge to force a decision when consensus can’t be achieved. Usually it’ll the same person who is a manager in organizational structure.

Roles

There’re 6 (7 in MSF 4.0) roles. It doesn’t mean that you have to have at least 6 people to create a MSF team. Some roles can be merged, so one person fulfills a couple of them. Every role can be fulfilled by more than a single person. Smallest MSF team counts 3 people. Guys from Microsoft say that the biggest effective MSF team counts about 20 people. There’re of course methods to scale MSF to bigger teams. I’ll write more on that in another article.

List of MSF roles contains: Product Management, Program Management, Development, Test, User Experience (former User Education), Release Operations (name brought by MSF 4.0; former Release Management from version 3.1 and Logistics from version 3.0). A new role introduced by new version MSF is Architecture.

Product Management

This role is responsible for delivering a solution that fulfills customer’s needs. Product manager is an advocate of customer for the team. Her main goal is to keep customer satisfied, so she usually tries to smuggle as many cool features into development as possible. Cool features are something customers would like for sure. Product manager usually talks with decision-makers, not users, so she’ll come with knowledge about things which are selling the product. The opposite role for product manager is

Program Management

This hard-working and undervalued role (OK, you got me – that’s my role) is responsible for delivering the solution with planned functionality, on time and in budget. Like someone said program manger should ensure that the right product is delivered on the right time. It’s obvious that program manager’s job is easier if there isn’t much to do – there’re no risks with deadlines or budget then. That’s why program manager will always try to cut as much functionality as possible. Product and program managers make a well-matched couple to fight... er... discuss product functionality. The program manager is usually the one who is “more equal”.

Development

Someone has to develop whatever those guys above would come with. Any volunteers? I talk to you, my developers... Developer is responsible for (you won’t believe) development. In MSF there are no designers and coders – both fulfill a development role. I think developer’s tasks are rather intuitive, so no detailed explanation is needed. Where there’s code there should be someone who will verify it. This is the task for

Test

Another easy to define role. Tester ensures that the product is stable, especially that it’s stable from customer perspective. She’s tasks covers not only verification if a program doesn’t have any bugs (of course it has), but also ensuring that functionality covers customer’s needs and fulfills requirements list. Tester should catch every issue like a bulldog and make sure it’s addressed (what a nice word) and resolved. It’s a cool role because you can be malicious and it counts as a positive.

User Experience

An advocate of a user for the team. The user, not the customer. There’s a great difference. Customer buys your software for his users. Users didn’t choose to work on your product, but still they can be happy (or in many cases unhappy) with it. Quality of people working in user experience is counted in user satisfaction rate. Preparing user documentation, forcing tiny improvements making the product user-friendlier, trainings, creating different materials dedicated for users (e.g. tips & tricks, FAQs etc) – these are all tasks for user experience.

Release Operations

This role delivers (in their own hands) the solution to the customer. Range of tasks performed by release operations varies the most within MSF roles. It can be just uploading a new version to the web site but it can be implementing whole solution in customer’s environment either. It’s hard to describe tasks performed by release managers, because it’ll differ vastly between the one whose goal is to put the boxes on the self and the one whose goal is to deliver a carrier grade system for e.g. mobile operator. A brainwave from MSF authors says the product delivery should be smooth (another nice word).


Architecture

Last but not least. The brand new role introduced by MSF 4.0 the architecture. It’s probably the greatest thing MSF 4.0 introduced. Architect is responsible for solution design on a high level. Integrating designer role into development works well, but when there’re many developers someone should coordinate their actions on higher level, yet still having technical background. Before MSF 4.0 this task usually landed on program manger shoulders, even though there were quite often a dedicated architect in the team whose role was defined rather different than program manager. Now, with MSF 4.0 issue disappeared and we have a new role for software architect. He’s a translator between program managers and developers. If you aren’t ashamed of code and design of the system after few years of development it’s a time to give your architect a raise. He’s performed well.

Defining Your Role

It’s very easy to define your own role (or roles) basing on elementary knowledge about MSF roles. After short practice it becomes very intuitive. It’s easy like whole MSF.

MSF Basics

Here is a list of posts from MSF Basics series and connected with MSF subject. I’ll update this list regularly after publishing successive articles from the series.

• MSF 4.0 versus MSF 3.1
• Risk Management
• Team Roles
• Process model
• Scaling up the team

And here are some original resources from Microsoft website which I strongly recommend when someone wants more than just a glance.

• MSF 4.0 homepage
• MSF 3.0/3.1 homepage

Say Thank You

Support team is a very special one. Sales usually finish their work on singing a contract. Project team, including project and/or product managers, designers, developers and testers, is done when implementation is completed and system works as it was designed (or quite different if it works at all). The only team who doesn’t have a choice to leave it all behind and go to next task is support. After successful implementation your first line is your support and they’re responsible for everyday contact with the customer.

Depending on a class of system you’ve delivered type contact with the customer can differ. It can be just dealing with issues submitted by users, especially when a system is big and was designed for single implementation or deeply customized. Carrier grade solutions or big implementations of ERP or CRM systems are good examples here. On the other hand there can be great percentage of feature requests, opinions, queries etc, especially when a product is addressed to large amount of end-users and isn’t individually customized for any of them. All “from-the-shelf” systems, from office suite to web applications, are good examples in that situation.

The latter case requires more skills, because you play not only for keeping customer satisfied with the system, but also for keeping customer satisfied with quality of contact and support. Those skills include, but are not limited to:

• Some abilities connected with answering a phone call. Controlling a timbre of voice. Right self-introduction. Rephrasing questions. There are many of them.

• Controlling emotions. It’s the customer who can allow himself to grow in anger, not the support person. Nothing good can happen if support person will show her emotions.

• Ability to write correctly. You can laugh, but I’ve seen so many mails from support, which authors (and the company) should be ashamed of.

• Ability to beat about the bush. Yeah, I hear your laughter much better now, but telling to the customer “Your data is lost. We have a bug somewhere but don’t know where yet. Regards. Pawel, Support Team” isn’t the best idea I’ve ever heard.

There’re more for sure – feel free to add them. Most of those skills can be learnt but it requires some effort. However there’s one thing you can apply easily which works perfectly. Every time you get some input (e.g. feature request, opinion about your product) which isn’t easy manageable (like bug submission) say “thank you”. And when you say it – mean it. Mean it even when a request is the best candidate to win Most Ridiculous Feature Request of the Year prize. Mean it even when you utterly don’t agree with an opinion. Thank for sharing opinion. Thank for feedback. Thank for time the customer spent on contacting you. It’s a win-win scenario – customer’s satisfaction grows and you increase a chance that you’ll get more feedback. Maybe another time it’ll be less ridiculous.

I recall two cases when I (as a user) contacted support with my thought about systems I was using. I sent some advices into black hole of GMail support. I haven’t received any answer. It was more than a year ago, maybe they’ve changed since than, but I rather won’t try any more. I don’t like to be ignored. No one likes. Second case was with (my favorite) Pandora. I received my “thank you” answer within few hours. Maybe GMail team took my opinion into consideration, but they didn’t send this message to me, so I assume they don’t. Pandora team let me know they care and that I’m important for them (even if I’m not), so they can count on me in the future. Very small effort results in great difference with user attitude.

Thank you in advance for sharing any future comments on this article. I look forward to see any remarks either supportive or critical. Your feedback is greatly appreciated.

MSF: Risk Management Basics

It’s the first post of series describing several concepts from Microsoft Solution Framework. Post will cover basics, so I strongly recommend original white papers if someone wants to make some deeper studies. Instead of going deep I’ll try to describe practical point of view. One more thing – I play with MSF 3.0/3.1 concepts. If you work with version 4.0 they can be hidden a bit now, but they’re still there – MSF 4.0 is an implementation of MSF 3.1.

Concept of risk management is quite obvious – it’s about predicting what (bad) can happen to a project. It’s like in a real life – before long journey we predict that car can brake down and it’ll completely ruin our holidays. The goal is to minimize a chance that out holidays will be poor... er... the project will go wrong.

First we need to define risks. Every member of a team can do that. Fact that idea of car braking down came from our 5-year old child doesn’t make the risk irrational. Saying that UFO can kidnap the driver is ridiculous – no matter who proposed that. In case of defining risks everyone’s invited.

Knowing just that my car can brake down doesn’t make it any better – rather worse because now I’m stressed. Just knowing what can go wrong isn’t enough. Some more information is needed: what to do to avoid the threat and what should we do if it became real. Overhauling a car is nice plan to avoid problems, calling a service would work well if something bad would happen despite our preventability. Now our risk is well equipped. It doesn’t matter who came with plans what to do – risk author or anybody else. What matters is that it’s known what to do.

OK, so we have our risk well-defined. What now? Now it’s essential to manage those risks. All of them? Definitely not. We rather don’t want to think what would happen when UFO came, because it won’t come. We don’t want to spend time analyzing what will happen when fly hits the car, because nothing will happen. At least in our lives. We need to measure somehow which risks are more important than others, so we count risk exposure. We get exposure by multiplying impact the risk has on us by probability that risk will happen. Impact of kidnapping the driver by UFO is great (close to 100% of scale), but the probability is... hmm... lower than zero. Probability of hitting some flies is close to 1 but I don’t think it will have any impact worth mentioning. At least for us. Possibility of car breaking down is rather low (but not zero) and impact is high, so exposure will be at some level. It’s more important issue to manage than two previous. Discuss only few positions from the top of the list. The rest is less important. If you’ve tried to manage all of them you wouldn’t have gone anywhere.

Who should decide about levels of probability and impact? Everyone’s invited. The driver probably isn’t an oracle in case of servicing car, and for sure he doesn’t know anything about flies’ life. Every member of the team should make his own vote. Then, exposure of the risk is counted as average of everyone’s exposures of that particular risk. Now, after sorting risks by exposure, we know what is perceived as greatest danger to the journey (or the project) on the very moment. Now, go implement your plan to avoid the risk. Go overhaul your car.

During journey threats can change. With perfectly serviced car exposure of materializing the risk of broken vehicle is very low. Now another position will go to the top of the list. Maybe it’ll be a child, who haven’t gone to WC and now exposure of dirtying upholstery on the back seat goes up. Minute after minute. How would you know that? By evaluating your risk on regular basis. It depends on project size and its stage, but generalizing a bit I find weekly evaluations working well. Make them not only on planning stage (preparations to journey/project/whatever) but during implementing phase also. Don’t be surprised if top 3/5/10 list changes when focus of a process is altered.

Easy? Easy! A piece of cake. That’s so natural. We do it everyday in the real life, why not try at work?

Series of MSF Basics won’t be very regular. I’ll try to write at least a post once every two weeks.

How to Improve Your Scheduling

It happens everyday. You’re asked about time you need to complete a task. The problem is that your schedules are usually far from reality. You’re not alone. Vast majority of us tend to underestimate efforts needed to complete the task. That’s oh so very common to see work done with significant time overrun. Especially developers excel in that category.

How to improve your estimates though? Two simple advices:

1. Use your past experience. Probably every single person asked to schedule something made it wrong at least few times. Very often we don’t even try to learn from that lesson. OK, I’d said it would have taken a week and after all it took more than fortnight. Why? Where I was wrong? Which assumptions were too optimistic? List things you should remember about. Use this list next time you’ll be asked to create some schedule.

2. Remember you’re not productive for the whole time. Think about all things you’ll do which can be predicted now. We tend to think that if a workday has 8 hours, we’ll spend 8 hours on the task. Forgetting things we do everyday (and can be predicted) doesn’t help to create better schedule. Think about:

• Coffee breaks. Let’s say two during a workday. 10 minutes for each (including smalltalk in a kitchen with colleagues).

• Weekly team meeting. An hour.

• More meetings? Sure. Project meetings twice a week. 3 hours.

• Some blogs and news check-up. A quarter after lunch.

• Major issues from support team. Once per fortnight. Half a day.

• Minor issues from support team. Twice per week. An hour per event.

• All those weird schedules updates, work assignments and so on. Who the heck force us to do all of that? A whole hour wasted weekly.

• Going to WC. Yep, it really takes time. 10 minutes daily.

• Writing necessary e-mails. 4 hours per week.

• Writing unnecessary e-mails. 4 hours per week.

• Deleting spam. 30 minutes weekly.

• Boss’ caviling. Quarter once per week.

Oh, is it really possible that I counted more than 4 hours every single workday? That’s half of the day! How can it be?

Another time think twice before you tell your boss that it’ll be ready on Friday.