You already know that the Game Boy Micro is small when you hear people tell you that it's just barely bigger than the cartridge that fits into it, but you don't really get a sense for just how small it is until you get your hands on it. Your thumb just about dwarfs it. The AC adapter for the system is nearly as big as the system it charges -- the charger is slightly thicker, almost exactly as tall, and a little more than half as wide. The whole system is smaller than just the screen on Sony's PSP. It almost fits inside a Nintendo DS game case. We're talking very, very small.
Flickr Badge
Sunday, August 28, 2005
IGN: GBA Micro
IGN reviews the GBA Micro:
Sunday, August 21, 2005
Agile Toolkit Podcast
Some really good interviews from Agile 2005 available here: Agile Toolkit Podcast
Friday, August 19, 2005
Weird formatting issues
If you've visited the blog in the last month or so, you would have noticed a weird CSS formatting issue which caused all the posts apart from the latest one to be shifted downwards, leaving a huge bit of white space. I decided to look at it today, and saw that it was a stray div tag with clear:both style causing the problem, but it seemed to be added automatically by blogger. After a lot of hair pulling, I came across this: Blogger Buzz: A Layout Solution
Evolution of Programming Languages Poster
We also printed out and put up this poster in the office: Evolution of Programming Languages Poster
Thursday, August 11, 2005
Opera Mini
All this while, Opera has mainly targetted higher end phones for their mobile browser. Today, they released Opera Mini. Opera Mini is a stripped down version of Opera which will run on lower end phones. It's written in Java, so the phone needs Java support. Instead of doing all the processing on the client (like they do in their full mobile browser), they have a proxy server that converts the data into a format suitable for the phone, and the client just renders that.
This is all VERY similar to the initial WAP idea, with one major difference: while the original WAP spec needed content developers to develop in WML, with Opera Mini you can visit the very same HTML sites that you do on your desktop. This is a big difference. One of the main reasons that WAP has not really caught on is because of the lack of quality mobile content (remember, you can't view HTML pages). The WAP 2 spec rectifies this by adding support for XHTML and CSS, but all the processing is done by the client. Opera have combined both ideas in Opera Mini.
There are still a number of potential pitfalls. Another reason why mobile browsing hasn't caught on was because of slow and expensive bandwidth. Yet another reason has been difficulty in reading on a small screen and clunky input via a telephone keypad. Neither of these have been solved. Opera uses compression and small screen rendering (which modifies the page to accomodate a small screen) to try to solve these problems, but the solutions have only been okay. I'd love to try it out to see how it scores on these points.
Opera Mini is only available in Norway at the moment (no idea why). Can't wait to try it out when it releases here.
This is all VERY similar to the initial WAP idea, with one major difference: while the original WAP spec needed content developers to develop in WML, with Opera Mini you can visit the very same HTML sites that you do on your desktop. This is a big difference. One of the main reasons that WAP has not really caught on is because of the lack of quality mobile content (remember, you can't view HTML pages). The WAP 2 spec rectifies this by adding support for XHTML and CSS, but all the processing is done by the client. Opera have combined both ideas in Opera Mini.
There are still a number of potential pitfalls. Another reason why mobile browsing hasn't caught on was because of slow and expensive bandwidth. Yet another reason has been difficulty in reading on a small screen and clunky input via a telephone keypad. Neither of these have been solved. Opera uses compression and small screen rendering (which modifies the page to accomodate a small screen) to try to solve these problems, but the solutions have only been okay. I'd love to try it out to see how it scores on these points.
Opera Mini is only available in Norway at the moment (no idea why). Can't wait to try it out when it releases here.
Wednesday, August 10, 2005
Links related to the previous two posts
I just ran into these links which are related to the previous two posts:
- Joel on Software - Incentive Pay Considered Harmful
- Why Individual Measurement is Bad
- Fog Creek Compensation
- Badge of Merit
- Microsoft's 3.0
Tuesday, August 09, 2005
Skill based promotions
I wrote mentioned a skill based promotion system in my essay yesterday. I've fleshed it out a bit more. Here is my current thinking on this topic.
When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.
A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.
Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.
Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.
Here is a plan on how to implement skill based promotions -
How can we come up with a list of skills? Here is one example -
Developer
Key Skills Required -
Project Manager
Key Skills Required -
Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -
For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.
One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.
The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:
And for Project Manager:
The above are just examples, and should be tweaked as required.
In my opinion, such a skill based promotion system is superior to a performance based promotion system.
This post is a part of the selected archive.
When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.
A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.
Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.
Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.
Here is a plan on how to implement skill based promotions -
- Write down a list of skills required for each role - apart from promotions, these lists of skills will also help in hiring
- Provide resources to enable employees to acquire those skills
- Promote them when they have acquired the relevant skills
How can we come up with a list of skills? Here is one example -
Developer
Key Skills Required -
- Thorough knowledge of the programming language
- Refactoring
- Knowledge of a unit testing framework
- Project architecture and design skills
- Estimation methods
- Design patterns
- Understanding of algorithms
- Code reading skills
Project Manager
Key Skills Required -
- Identifying and managing project risks
- Estimation methods, formal and informal
- People and communication skills
- Knowledge of at least one traditional process and one agile process
- General management skills
- Good technical knowledge to understand problems faced by the team (Although this is not strictly required, programmers do respect their managers a lot more if they are technically oriented)
- Some amount of domain knowledge
- Basic understanding of the target end user - this is needed because the project manager is the user advocate in the team
- Understanding of the technical environment - source control, testing methods used etc
Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -
- Allowing them to attend seimnars, workshops and conferences
- Filling up the company library with relevant books and magazines
- Enabling them to form ad-hoc learning groups
For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.
One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.
The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:
- Developer [0/8 skills]
- Senior Developer [3/8 skills]
- Technical Designer [6/8 skills]
- Senior Technical Designer [8/8 skills]
And for Project Manager:
- Project Lead [5/9 skills]
- Project Manager [9/9 skills]
- Program Manager [9/9 skills + sucessful completion of at least two projects]
The above are just examples, and should be tweaked as required.
In my opinion, such a skill based promotion system is superior to a performance based promotion system.
This post is a part of the selected archive.
Monday, August 08, 2005
Merit Based Pay
Conventional wisdom tells us to take the top performers and reward them highly. The theory goes that if they aren't recognised and rewarded, they will soon leave to better opportunities elsewhere. Even if they don't leave, they will soon be demotivated and put in an effort comparable to the weaker performers. After all, the reward is going to be the same!
Conventional wisdom is wrong.
Do not reward the better programmers any more than the weaker programmers.
By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.
The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:
If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.
Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.
In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.
One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?
Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.
The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.
Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.
Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.
Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.
No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.
This post is a part of the selected archive.
Conventional wisdom is wrong.
Do not reward the better programmers any more than the weaker programmers.
By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.
The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:
Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:
- Annual salary or merit reviews
- Management by objectives (MBO)
- Praise of certain workers for extraordinary accomplishment
- Awards, prizes, bonuses tied to performance
- Performance measurement in almost any form
If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.
Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.
In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.
One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?
Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.
The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.
Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.
Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.
Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.
No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.
This post is a part of the selected archive.
Saturday, August 06, 2005
Links to Agile Methodologies
Here are links to some other agile methodologies -
Friday, August 05, 2005
Strunk, William, Jr. 1918. The Elements of Style
I just went out and bought this book: Strunk, William, Jr. 1918. The Elements of Style
Tuesday, August 02, 2005
Source Insight
Source Insight is THE BEST code editor I've seen. It is totally, staggeringly, awesome. Especially if you are coding in C. It has pushed vim onto No.2 on my list now. It's way better than VC++. Much better than eclipse.
I've not used IntelliJ so I can't comment on that. I've heard a lot of good things about it, so if you are into Java programming you may want to investigate it along with Source Insight. But for C programming, it simply blows everything else away.
Now, VC++ and eclipse may have more features, but this still beats them. Why? It provides contextual information about whatever symbol is under the cursor. It makes navigating to different functions a snap. It can keep many, many files open at a time. And its FAST. Did I say FAST? I meant amazingly, blindingly FAST. Eclipse can barely run on my system, let alone allow me to keep twenty files open at a time. Source Insight lets me do it.
Did I mention smart rename? It allows me to rename a variable or function name, and it will rename the function everywhere its called. I know it's there in eclipse, but eclipse is such a slow behemoth that I just can't stand it.
Forget coding. Source Insight make READING code so easy. I can travel between various functions in seconds. I can see where all a function is called from. It formats the code beautifully. I can see function names and variable names so easily. They just pop out when you're looking for them.
Oh, and did I mention smart searching? Smart searching allows you to search symbols from the entire project. So you dont have to remember which file contains the function you want to see. What is more, you can type just a few characters of symbol to see it. That's available everywhere, right? Not when those characters can be from the middle of the function or variable name. Still, its been done in other IDEs. But not when its a similarity search, so you can search for "styleAdd" and it will find "displayAddStyleProperty". This is great when you don't know the exact name of the function but you have an idea that its got something to do with styles. This feature alone makes Source Insight more worthwhile than anything else.
Check out the trial version. You can download it here.
I don't use IDEs to read and write code anymore. I just use them for compiling and debugging. Source Insight actually makes me enjoy using it. This is how software should be written. It's awesome. I'm converted.
This post is a part of the selected archive.
I've not used IntelliJ so I can't comment on that. I've heard a lot of good things about it, so if you are into Java programming you may want to investigate it along with Source Insight. But for C programming, it simply blows everything else away.
Now, VC++ and eclipse may have more features, but this still beats them. Why? It provides contextual information about whatever symbol is under the cursor. It makes navigating to different functions a snap. It can keep many, many files open at a time. And its FAST. Did I say FAST? I meant amazingly, blindingly FAST. Eclipse can barely run on my system, let alone allow me to keep twenty files open at a time. Source Insight lets me do it.
Did I mention smart rename? It allows me to rename a variable or function name, and it will rename the function everywhere its called. I know it's there in eclipse, but eclipse is such a slow behemoth that I just can't stand it.
Forget coding. Source Insight make READING code so easy. I can travel between various functions in seconds. I can see where all a function is called from. It formats the code beautifully. I can see function names and variable names so easily. They just pop out when you're looking for them.
Oh, and did I mention smart searching? Smart searching allows you to search symbols from the entire project. So you dont have to remember which file contains the function you want to see. What is more, you can type just a few characters of symbol to see it. That's available everywhere, right? Not when those characters can be from the middle of the function or variable name. Still, its been done in other IDEs. But not when its a similarity search, so you can search for "styleAdd" and it will find "displayAddStyleProperty". This is great when you don't know the exact name of the function but you have an idea that its got something to do with styles. This feature alone makes Source Insight more worthwhile than anything else.
Check out the trial version. You can download it here.
I don't use IDEs to read and write code anymore. I just use them for compiling and debugging. Source Insight actually makes me enjoy using it. This is how software should be written. It's awesome. I'm converted.
This post is a part of the selected archive.
Subscribe to:
Posts (Atom)