A little while ago I was at a house party. I got talking to a fellow who does creative work for marketing campaigns. I asked him if it's true that two thirds of the money spent on advertising is wasted. He agreed that it was.
He said with advertising you can have it fast cheap or good, pick two. That rule applies in a lot of areas. I remember the first time I saw fast cheap good. It was a sign on the wall of an auto body shop when I was a child.
A veteran developer at the office who has team led some key projects in company history had a slight twist on it with software projects. In a software project ther are four variables that are naturally balanced against each other. They are scope, schedule, resources and quality.
Scope is the features contained in the release. Sometimes the scope is based on a sale or a contract agreement so all of the features must be implemented to get paid. Sometimes with a more internally defined project there may be room to cut or scale back features so the project can be completed within the desired timeframe. Problems can occur in a software project when the original scope expands. If scope increases then this must be balanced against the other three factors. The problems can occur when features are just "added" but no allowance is made in terms of resources or schedule for the new work.
Like scope, schedule is often pre set based on external agreements so cannot be changed. Sometimes in a project this is the one variable which does not change throughout. Often the software team is evaluated by meeting scheduled dates above any other objective. Of the four project variables schedule is often the most difficult one to change after the project begins.
Scope and schedule are often balanced against each other. I've been on many projects over the years where somebody wanted to add something during the project. When the project manager informs that any addition in scope can only be accomodated by slipping the schedule, the feature request goes away. I can recall many instances over the years where the person requesting the feature changed his mind when faced with a schedule slip. I can't recall a single time when someone agreed to slip a schedule of an in progress software project in order to add new features.
Resources generally means the head count of people working on the project. This can be increased somewhat if necessary. But as Brooks points out, you quickly reach a point of diminishing returns when adding resources. One type of resource which is often added is overtime. That allows the team to stay smaller and more manageable while being able to get more done in the same amount of calendar time. Overtime does have its costs though as quality tends to slip in the long sessions and the extra hours tend to be less productive per hour as it adds up.
Which brings it to quality. The reality is that quality tends to be the easiest place to take the hit on when a project is too big and too complex for the time and resources allocated. The thing about quality as opposed to say features or schedule is that the programming team does not have to get permission to slip on it. It can just happen and nobody knows about the quality issues until after the fact.
Unlike a schedule slip or missing features, a quality shortcoming is not immediately obvious. So it's easier to maintain an illusion of a successful software project when in fact the project was not as successful as hoped. A quality slip can take different forms besides obvious defects in the running product. Low quality can appear when the code is poorly structured and hard to maintain. Code copy and paste is used instead of refatoring common pieces. Javadoc and JUnit is skimpy or skipped entirely. Quality can appear as an unintuitive user interface lacking polish. Quality problems can appear in the form of low performance or crashes under load.
For the develment team lead and manager, when a software project is getting started they need to communicate to the stakeholders the factors that are always balanced. Sometimes the people outside the development team want to push for lots of major features and an aggressive schedule. The software team needs to communicate clearly up front when it is obvious that the hit will be on quality if that is the only factor which is allowed to vary.
Saturday, June 02, 2007
Friday, May 04, 2007
High Tech and the Monkeys
You may have heard the story of the monkeys and the cold water.
http://www.mountainhome.af.mil/news/story.asp?id=123027878
http://www.eve-tribune.com/index.php?no=1_26&page=4
I'm sure this happens in all industries, and it can happen a lot in high tech. What happens is that at some point there is some limitation, restriction, bug, inexperience, or lack of knowledge about some technology. So we start doing things in a certain non-optimal way to work around the bug or because we didn't know the correct way at the time. The incorrect way becomes the standard and we continue doing things that way far into the future, long after the original constraint has disappeared.
The thing with software is that we are often using leading edge technology. Often the new technology can contain bugs or limitations that requires workarounds that are kludgy, ugly or verbose. In later releases the problems from the earlier releases are fixed so the workarounds are no longer required. However the workarounds become standardized so we don't update the old code and continue to write new code to the old ways.
Also because of schedules we don't always have time to fully explore the libraries we work with. So if a new version of something comes out that makes it easier to accomplish some task, the programmers might not even know about it because they didn't explore all the new features and fixes in the new release. They just use the old code with the new libraries.
So you might come across stuff like this as generic examples.
Q: Why do we use all this verbose formatting instead of printf?
A: printf wasn't around until Java 1.5. This code was written before that so we did it that way.
Q: Why is the security stuff with JSP, EJB and roles so strange?
A: Well, _blank_ who doesn't work here anymore, set it up this way originally years ago. Plus there was a requirement at the time which was later dropped for a special 'guest user' mode that we had to accomodate. It just became the standard and was never revisited once it was working.
Q: Why is there so much awkwardness around setting and getting DATE fields with the database.
A: Originally five years ago there was a bug in the Oracle JDBC driver so we had to do these ugly workarounds with dates and UTC.
Q: But that JDBC driver bug was fixed years ago.
A: Yes well we didn't realize it was fixed and once we got it working after much pain it just became the standard way.
When new people join an established team with an older (like 2+ years) code base then the new person will often have a fresh untainted perspective and can point out some stuff that the existing developers were doing wrong or non-optimally. Sometimes the original developers will not be aware of all the newest library features, or will be operating under old constraints that no longer exist.
If you join a new team and are working with new technology and the existing code base is several years old, you may see stuff that might not make a lot of sense. There's a good reason it's there because of the monkeys.
http://www.mountainhome.af.mil/news/story.asp?id=123027878
http://www.eve-tribune.com/index.php?no=1_26&page=4
I'm sure this happens in all industries, and it can happen a lot in high tech. What happens is that at some point there is some limitation, restriction, bug, inexperience, or lack of knowledge about some technology. So we start doing things in a certain non-optimal way to work around the bug or because we didn't know the correct way at the time. The incorrect way becomes the standard and we continue doing things that way far into the future, long after the original constraint has disappeared.
The thing with software is that we are often using leading edge technology. Often the new technology can contain bugs or limitations that requires workarounds that are kludgy, ugly or verbose. In later releases the problems from the earlier releases are fixed so the workarounds are no longer required. However the workarounds become standardized so we don't update the old code and continue to write new code to the old ways.
Also because of schedules we don't always have time to fully explore the libraries we work with. So if a new version of something comes out that makes it easier to accomplish some task, the programmers might not even know about it because they didn't explore all the new features and fixes in the new release. They just use the old code with the new libraries.
So you might come across stuff like this as generic examples.
Q: Why do we use all this verbose formatting instead of printf?
A: printf wasn't around until Java 1.5. This code was written before that so we did it that way.
Q: Why is the security stuff with JSP, EJB and roles so strange?
A: Well, _blank_ who doesn't work here anymore, set it up this way originally years ago. Plus there was a requirement at the time which was later dropped for a special 'guest user' mode that we had to accomodate. It just became the standard and was never revisited once it was working.
Q: Why is there so much awkwardness around setting and getting DATE fields with the database.
A: Originally five years ago there was a bug in the Oracle JDBC driver so we had to do these ugly workarounds with dates and UTC.
Q: But that JDBC driver bug was fixed years ago.
A: Yes well we didn't realize it was fixed and once we got it working after much pain it just became the standard way.
When new people join an established team with an older (like 2+ years) code base then the new person will often have a fresh untainted perspective and can point out some stuff that the existing developers were doing wrong or non-optimally. Sometimes the original developers will not be aware of all the newest library features, or will be operating under old constraints that no longer exist.
If you join a new team and are working with new technology and the existing code base is several years old, you may see stuff that might not make a lot of sense. There's a good reason it's there because of the monkeys.
Monday, April 30, 2007
How to code an inline Java Thread
This is an example for how to create an inline Java thread and launch it. The Thread Javadoc describes it in pieces and this is a complete example.
The output from the program will be someting like this.
import java.util.Date;
public class InlineThreadDemo {
public static void main(String[] args) {
System.out.println(
"parent thread " + new Date(System.currentTimeMillis()));
// launch child thread using inline declaration
new Thread(
new Runnable() {
public void run() {
try {
Thread.sleep(10 * 1000);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(
"child thread " + new Date(System.currentTimeMillis()));
}
}).start();
System.out.println(
"parent thread " + new Date(System.currentTimeMillis()));
}
}
The output from the program will be someting like this.
parent thread Mon Apr 30 22:14:02 ADT 2007
parent thread Mon Apr 30 22:14:02 ADT 2007
child thread Mon Apr 30 22:14:12 ADT 2007
Wednesday, April 04, 2007
Dial tone, kleenex, Google
I got talking a little while ago with a smart guy at work. He's a veteran developer, doing it longer than I have. We have some similar views about how software should be built.
Anyway we got talking about software quality and reliability, a favorite subject. Of course when the subject is reliability the discussion immediately goes to dial tone. That was kind of interesting, we don't talk about dial tone in terms of reliability. We talk about reliability in terms of dial tone. So dial tone ends up defining reliability instead of the other way around.
It can be pretty good when you have so much mind share that the product ends up defining the term instead of the other way around. For example a guy's girlfriend could ask him to pick up some Puffs Kleenex at the drug store when he's there. That request makes good sense because everyone uses the term Kleenex to describe facial tissue. If someone says to "Google" on something, they of course mean to look it up on the Internet using a search engine.
Usually when creating software or some other product you want to achieve that kind of dial tone, kleenex, Google status. You want to have so much mind share that people define the term using the product instead of the other way around.
However there can be a downside to this if the association is a negative one. For example if someone says something is a "1.0" thing, what they mean is the historic negative experience with the version 1 release of software. That is full of bugs, slow, underfeatured, hard to use. It may not even be called version 1.0, but someone can call it that and then you're in trouble.
Another example would be calling something a "WordPerfect 6.0 for Windows". WP 6.0 for Windows is the definition of the horrible product release. Delivered late, it was extremely unstable, crashing constantly, losing data and frustrating users. That product release was a blow from which WordPerfect never recovered.
Interestingly I know a fellow who was a WP fan. He of course agreed that 6.0 for Windows was bad. However he said 6.1 was much more stable, and by 6.2 they had a good solid product. Unfortunately for WordPerfect, by the time 6.2 was out they had lost virtually all of their market share to Microsoft Word, so 6.2 was pretty much irrelevant. I wonder how many people out there know that 6.2 is pretty good, compared to those who know that 6.0 wasn't. Probably not too many. After 6.0, most people like me just tuned out WordPerfect.
So when someone calls something a "WP 6 for Windows" then you know that it's a bug filled disaster, even if the product has nothing at all to do with word processing.
Anyway we got talking about software quality and reliability, a favorite subject. Of course when the subject is reliability the discussion immediately goes to dial tone. That was kind of interesting, we don't talk about dial tone in terms of reliability. We talk about reliability in terms of dial tone. So dial tone ends up defining reliability instead of the other way around.
It can be pretty good when you have so much mind share that the product ends up defining the term instead of the other way around. For example a guy's girlfriend could ask him to pick up some Puffs Kleenex at the drug store when he's there. That request makes good sense because everyone uses the term Kleenex to describe facial tissue. If someone says to "Google" on something, they of course mean to look it up on the Internet using a search engine.
Usually when creating software or some other product you want to achieve that kind of dial tone, kleenex, Google status. You want to have so much mind share that people define the term using the product instead of the other way around.
However there can be a downside to this if the association is a negative one. For example if someone says something is a "1.0" thing, what they mean is the historic negative experience with the version 1 release of software. That is full of bugs, slow, underfeatured, hard to use. It may not even be called version 1.0, but someone can call it that and then you're in trouble.
Another example would be calling something a "WordPerfect 6.0 for Windows". WP 6.0 for Windows is the definition of the horrible product release. Delivered late, it was extremely unstable, crashing constantly, losing data and frustrating users. That product release was a blow from which WordPerfect never recovered.
Interestingly I know a fellow who was a WP fan. He of course agreed that 6.0 for Windows was bad. However he said 6.1 was much more stable, and by 6.2 they had a good solid product. Unfortunately for WordPerfect, by the time 6.2 was out they had lost virtually all of their market share to Microsoft Word, so 6.2 was pretty much irrelevant. I wonder how many people out there know that 6.2 is pretty good, compared to those who know that 6.0 wasn't. Probably not too many. After 6.0, most people like me just tuned out WordPerfect.
So when someone calls something a "WP 6 for Windows" then you know that it's a bug filled disaster, even if the product has nothing at all to do with word processing.
Monday, March 05, 2007
Cashed in stock options
I recently experienced something that many in high tech get to do. I cashed in some stock options. I often didn't think I'd ever get to. The first options I was granted were in 2001 with my previous employer. And it's only now that I saw anything from them.
The company stock price unfortunately tumbled after they acquired my previous employer. When we joined we were granted options. We've also gotten additional options at annual review. In the subsequent grants, the stike price was lower based on the lower stock price.
With the new CEO, the company has done better, and the market price has improved. Some of the options in the subsequent grants are now modestly in the black. So I decided to cash some. I would have preferred to wait because they aren't far in the black at this point and the company has a strong upside potential. However I have some short term financial issues which unfortunately created a need for a shorter term view of things.
I didn't know what the process was to cash out. I thought it would be just click some buttons and the money would be there. There was a bit more to it than that; it's an interesting process which requires a bit of patience.
Our company employee stock plan is handled by e*trade. Once the trading window was open I logged in. etrade has an excellent user interface and bringing up the screen and selecting the 750 option shares to cash on a same day sale was very easy and intuitive. So on the first eligible day, a Tuesday, I did the clicks and the order was executed immediately as expected. Great.
But then I was a bit surprised. The execution was immediate but then I learned that the trade was not "settled". The help said settling takes around 3 business days, but sometimes longer for employee stock plans. Well Friday came and went and it was still unsettled. It wasn't until the next Friday that it settled, 10 days after the execution.
I got the etrade e-mail saying it was settled and was excited. But then there's another step. After settling it takes a bit longer for the proceeds to get into my etrade account. So Friday became Monday and then the money was there.
Now to spend the money I had to get it from my etrade account into my regular chequing account. I had a link set up between my etrade account and my chequing account. It was very simple to do the cash transfer between the etrade US money stock account and my Canadian bank account. But this time I wasn't surprised when it said it would be the next day for the money to appear in my bank account.
Finally the next morning the proceeds from the stock options was indeed in my bank account. It was two weeks after the order execution. So now I know what to expect. I hope to be able to cash out some more options. If the stock price can go up by around $2, then that would be very nice. At that level our original grant after the takeover, which is the largest grant, would be worth cashing. Also due to some SOX accounting thing or whatever, our original grants are actually fully vested, so the potential gain would be pretty nice.
All together I cleared an amount about equal to the take home pay from one paycheque. We get paid twice a month. So not bad, can't complain. It was a nice reward for the hard work over the years. I still have lots of options uncashed so if we can have a nice stock price run then that could be good for me.
For etrade I give them a very positive review. Their site is excellent. It's secure and easy to use. The user interface is laid out logically and navigation is straightforward. There's plenty of context help. With the alerts I always knew what was going on through the process. In the future I hope to be able do some investments again. I would be inclined to use etrade for that based on my experiences with them here.
The company stock price unfortunately tumbled after they acquired my previous employer. When we joined we were granted options. We've also gotten additional options at annual review. In the subsequent grants, the stike price was lower based on the lower stock price.
With the new CEO, the company has done better, and the market price has improved. Some of the options in the subsequent grants are now modestly in the black. So I decided to cash some. I would have preferred to wait because they aren't far in the black at this point and the company has a strong upside potential. However I have some short term financial issues which unfortunately created a need for a shorter term view of things.
I didn't know what the process was to cash out. I thought it would be just click some buttons and the money would be there. There was a bit more to it than that; it's an interesting process which requires a bit of patience.
Our company employee stock plan is handled by e*trade. Once the trading window was open I logged in. etrade has an excellent user interface and bringing up the screen and selecting the 750 option shares to cash on a same day sale was very easy and intuitive. So on the first eligible day, a Tuesday, I did the clicks and the order was executed immediately as expected. Great.
But then I was a bit surprised. The execution was immediate but then I learned that the trade was not "settled". The help said settling takes around 3 business days, but sometimes longer for employee stock plans. Well Friday came and went and it was still unsettled. It wasn't until the next Friday that it settled, 10 days after the execution.
I got the etrade e-mail saying it was settled and was excited. But then there's another step. After settling it takes a bit longer for the proceeds to get into my etrade account. So Friday became Monday and then the money was there.
Now to spend the money I had to get it from my etrade account into my regular chequing account. I had a link set up between my etrade account and my chequing account. It was very simple to do the cash transfer between the etrade US money stock account and my Canadian bank account. But this time I wasn't surprised when it said it would be the next day for the money to appear in my bank account.
Finally the next morning the proceeds from the stock options was indeed in my bank account. It was two weeks after the order execution. So now I know what to expect. I hope to be able to cash out some more options. If the stock price can go up by around $2, then that would be very nice. At that level our original grant after the takeover, which is the largest grant, would be worth cashing. Also due to some SOX accounting thing or whatever, our original grants are actually fully vested, so the potential gain would be pretty nice.
All together I cleared an amount about equal to the take home pay from one paycheque. We get paid twice a month. So not bad, can't complain. It was a nice reward for the hard work over the years. I still have lots of options uncashed so if we can have a nice stock price run then that could be good for me.
For etrade I give them a very positive review. Their site is excellent. It's secure and easy to use. The user interface is laid out logically and navigation is straightforward. There's plenty of context help. With the alerts I always knew what was going on through the process. In the future I hope to be able do some investments again. I would be inclined to use etrade for that based on my experiences with them here.
Sunday, February 11, 2007
Timestamps and productivity
A few years back with the company that my current employer acquired there was this big death march development project. The project was crucial to all the good things that happened later and everyone was on board with it.
I was arriving for work at a crazy early time and working steadily through the day, leaving around regular end of day time.
There was this other guy I noticed who arrived shortly before 8 each morning. He'd still be there when I left. I noticed that he'd be sending out e-mails and doing check ins around 8:30 in the evening. I thought at the time, man that guy is putting in long hours, a solid 12+ hours a day.
A few months later in the lunch room we happened to get talking about that project. I mentioned about the long hours he'd worked on it. His reply surprised me. He said that he'd just been working around 7:45 AM to a bit after 5 PM each day. Then he'd log in remotely at night from around 8:30 PM to 9 PM. It was while logged in remotely that he'd continue with what he'd been doing during the day. Hence the evening e-mails and check ins. To me not realizing about remote desktop it seemed that he'd been working longer hours than what he did.
Remote desktop is nice. It's great when you have family commitments and such. You can get home at the usual time and when necessary log in from like 8 PM and work several hours from home if necessary, while not being disruptive to family responsibilities.
My company is good in that we care about the amount and quality of work that people do, not the hours worked. Some companies unfortunately are preoccupied with hours worked, although this has limited correlation to quality and productivity. There's stories over on Joel on Software about people staying a couple of hours late in the evening to work on something, then going home and waking up 3 AM to dash off a quick 'done' e-mail and getting all this credit for pulling an all nighter because some PHB was obsessed with e-mail timestamps.
Still, it's important to get credit for all the work that you do. So if you're topping up your regular work day by logging in remotely then it's good to send out an e-mail in the evening or do a check in. It makes you look good and draws attention to the extra work you do. Also it's not a bad habit to invest 10-15 minutes in the evenings to log in remotely and check your late day e-mail that might have come in after you left. It will make you look good if you can reply before the next morning.
I was arriving for work at a crazy early time and working steadily through the day, leaving around regular end of day time.
There was this other guy I noticed who arrived shortly before 8 each morning. He'd still be there when I left. I noticed that he'd be sending out e-mails and doing check ins around 8:30 in the evening. I thought at the time, man that guy is putting in long hours, a solid 12+ hours a day.
A few months later in the lunch room we happened to get talking about that project. I mentioned about the long hours he'd worked on it. His reply surprised me. He said that he'd just been working around 7:45 AM to a bit after 5 PM each day. Then he'd log in remotely at night from around 8:30 PM to 9 PM. It was while logged in remotely that he'd continue with what he'd been doing during the day. Hence the evening e-mails and check ins. To me not realizing about remote desktop it seemed that he'd been working longer hours than what he did.
Remote desktop is nice. It's great when you have family commitments and such. You can get home at the usual time and when necessary log in from like 8 PM and work several hours from home if necessary, while not being disruptive to family responsibilities.
My company is good in that we care about the amount and quality of work that people do, not the hours worked. Some companies unfortunately are preoccupied with hours worked, although this has limited correlation to quality and productivity. There's stories over on Joel on Software about people staying a couple of hours late in the evening to work on something, then going home and waking up 3 AM to dash off a quick 'done' e-mail and getting all this credit for pulling an all nighter because some PHB was obsessed with e-mail timestamps.
Still, it's important to get credit for all the work that you do. So if you're topping up your regular work day by logging in remotely then it's good to send out an e-mail in the evening or do a check in. It makes you look good and draws attention to the extra work you do. Also it's not a bad habit to invest 10-15 minutes in the evenings to log in remotely and check your late day e-mail that might have come in after you left. It will make you look good if you can reply before the next morning.
Subscribe to:
Posts (Atom)