My son exclaimed, "Hey Dad, watch me jump off the couch!"
"Be careful." I replied.
Be careful.
It's usually the first response out of my mouth when my son's about to attempt something that I think could remotely harm him. But it struck me recently that "Be careful" may be the least constructive bit of parenting that I could conjure at any point in time.
I contemplate if that canned automatic response, though certainly well-meaning, is slooowly prodding my son down the well-traveled path of mediocrity; if my intentions of raising a child that has any chance of thriving in an ever-scarier world are actually being undermined by such an insipid response.
When I think of Great people, "being careful" is definitely down the list of personality traits and practices that I'd attribute to their greatness.
What about Happiness? Obviously Greatness and Happiness are significantly different. But I think the two are entwined in a way that is affected by a child's upbringing.
Is my son destined for Greatness? That's nearly impossible to answer. But is my son less destined for greatness after growing up on a steady diet of stale notions and empty advice? My careful mind is telling me yes.
Saturday, May 28, 2005
Friday, May 20, 2005
Java vs. C# Series: Productivity 2
C# developers have a dirty little secret. We all have a list of annoyances, bugs, and workarounds that we deal with every day while we write C# code. These are the Anti-Productivity features of C# .NET.
I was first clued into this at the beginning of my .NET tenure when all the controls disappeared from a form I'd been working on for days. We had just hired an experienced C# programmer to mentor the Java guys as we got up to speed with .NET. When I brought him over to my desk and showed him what had happened he said, "ohh, yeah, sometimes controls do that with WinForms in Visual Studio..." This was the beginning of a long personal list of problems and subsequent workarounds that I've now collected over the past year.
See for yourself. Go to Google or Google Groups and search for "A failure occurred while attempting to start the compilation." This little goodie happens randomly as you compile your project throughout the day; meaning, you'll be working happily for the first few hours of the day then you go into compiler hell for the next two hours. The kicker is that it seems to happen AFTER the compilation is complete. And the problem is obvious by its description, isn't it?!
Or how about this ugly little compiler error: "The process cannot access the file because it is being used by another process." Which file? Who knows!? Which process? Who knows!? Microsoft knows about this one and it looks like it will be fixed with VS 2005. That's no consolation to developers using VS 2003 every day. All that's painfully clear is the stress you might have been feeling before from a project deadline has now been magnified 100 times because you can't get a BUILD for CRYING OUT LOUD!
Also, as you're perusing the problems people are reporting on the web, notice that there aren't many answers out there. Dr. Spock! This... doesn't appear... to be... open source. And does Microsoft really have the gall to charge for a patch that fixes something that Visual Studio should just DO anyway?
The reason these annoyances frustrate me so much is because I can't remember dealing with bugs like these while programming in Java. And although I probably have, the point is, its such an extraordinary circumstance that I don't remember. I can remember using JBuilder and NetBeans years ago and being frustrated with their performance; but at least they worked properly. I do run Eclipse now. I can say that my experience with Eclipse' performance is much worse than my experience running Visual Studio. Then again, I work with code on a remote location when I'm running Eclipse. And frankly, Eclipse does exactly what I need it to every single time I run it. In any case, I think there's a subtle but significant difference between performance issues and things that just plain break. It was fascinating to me how our experienced C# guy was just resigned to the fact that this was normal. I guess I'm there too to some extent...
So to join this back in with my Productivity thread, I just want to make it clear that I truly have been more productive using C# .NET... but I could be so much more productive if I didn't have to deal with all of these inexplicable issues.
I was first clued into this at the beginning of my .NET tenure when all the controls disappeared from a form I'd been working on for days. We had just hired an experienced C# programmer to mentor the Java guys as we got up to speed with .NET. When I brought him over to my desk and showed him what had happened he said, "ohh, yeah, sometimes controls do that with WinForms in Visual Studio..." This was the beginning of a long personal list of problems and subsequent workarounds that I've now collected over the past year.
See for yourself. Go to Google or Google Groups and search for "A failure occurred while attempting to start the compilation." This little goodie happens randomly as you compile your project throughout the day; meaning, you'll be working happily for the first few hours of the day then you go into compiler hell for the next two hours. The kicker is that it seems to happen AFTER the compilation is complete. And the problem is obvious by its description, isn't it?!
Or how about this ugly little compiler error: "The process cannot access the file because it is being used by another process." Which file? Who knows!? Which process? Who knows!? Microsoft knows about this one and it looks like it will be fixed with VS 2005. That's no consolation to developers using VS 2003 every day. All that's painfully clear is the stress you might have been feeling before from a project deadline has now been magnified 100 times because you can't get a BUILD for CRYING OUT LOUD!
Also, as you're perusing the problems people are reporting on the web, notice that there aren't many answers out there. Dr. Spock! This... doesn't appear... to be... open source. And does Microsoft really have the gall to charge for a patch that fixes something that Visual Studio should just DO anyway?
The reason these annoyances frustrate me so much is because I can't remember dealing with bugs like these while programming in Java. And although I probably have, the point is, its such an extraordinary circumstance that I don't remember. I can remember using JBuilder and NetBeans years ago and being frustrated with their performance; but at least they worked properly. I do run Eclipse now. I can say that my experience with Eclipse' performance is much worse than my experience running Visual Studio. Then again, I work with code on a remote location when I'm running Eclipse. And frankly, Eclipse does exactly what I need it to every single time I run it. In any case, I think there's a subtle but significant difference between performance issues and things that just plain break. It was fascinating to me how our experienced C# guy was just resigned to the fact that this was normal. I guess I'm there too to some extent...
So to join this back in with my Productivity thread, I just want to make it clear that I truly have been more productive using C# .NET... but I could be so much more productive if I didn't have to deal with all of these inexplicable issues.
Friday, May 13, 2005
Moneyball for Software
In Moneyball, author Michael Lewis outlines 5 simple rules that Billy Beane, General Manager of the Oakland Athletics, kept in mind as he was shopping for players just before the trading deadline:
#1 is interesting. As a software developer I'm trying to gain new skills every single day. I've often found that when you start to get comfortable it starts getting dangerous for your career. Newer, better technologies are released out to the world every single day. I think a fundamental misunderstanding that business managers without a background in software have is that software and systems are like a car: when they get to the end of the assembly line they're done. In reality, software and systems are a moving target and need to be considered and managed as such.
The interesting part about his second sentence in #1 is true, you need to get something out as quickly as possible in a small software company and this process needs to be repeated many many times in rapid succession. However, taking on revenue at all costs and building short term software solutions can eventually become your costs when you do get bigger.
Point #2 touches on something similar that Marc Andreesen, co-founder of Netscape (who?), once said when asked about his next challenges at the company. He said something to the effect of, "protecting against bringing on mediocre people." Jack Welch also talks about this in Winning. Companies without a stable and thoughtful hiring plan can easily end up hiring basically the first ones in the door out of necessity for a warm body or the necessity to find the cheapest labor. Likewise, companies without a stable and thoughtful technology strategy can find themselves locked in by past mistakes. Panic sets in and more bad decisions are made. Really, the market conditions snuck up and something that could have been predictable ends up hurting those companies in the long run.
- "No matter how successful you are, change is always good. There can never be a status quo. When you have no money you can't afford long-term solutions, only short-term ones. You have to always be upgrading. Otherwise you're fucked."
- "The day you say you have to do something, you're screwed. Because you are going to make a bad deal. You can always recover from the player you didn't sign. You may never recover from the player you signed at the wrong price."
- "Know exactly what every player in baseball is worth to you. You can put a dollar figure on it."
- "Know exactly who you want and go after him." (Never mind who they say they want to trade.)
- "Every deal you do will be publicly scrutinized by subjective opinion. If I'm [IBM CEO] Lou Gerstner, I'm not worried that every personnel decision I make is going to wind up on the front page of the business section. Not everyone believes that they know everything about the personal computer. But everyone who ever picked up a bat thing he knows baseball. To do this well, you have to ignore the newspapers."
#1 is interesting. As a software developer I'm trying to gain new skills every single day. I've often found that when you start to get comfortable it starts getting dangerous for your career. Newer, better technologies are released out to the world every single day. I think a fundamental misunderstanding that business managers without a background in software have is that software and systems are like a car: when they get to the end of the assembly line they're done. In reality, software and systems are a moving target and need to be considered and managed as such.
The interesting part about his second sentence in #1 is true, you need to get something out as quickly as possible in a small software company and this process needs to be repeated many many times in rapid succession. However, taking on revenue at all costs and building short term software solutions can eventually become your costs when you do get bigger.
Point #2 touches on something similar that Marc Andreesen, co-founder of Netscape (who?), once said when asked about his next challenges at the company. He said something to the effect of, "protecting against bringing on mediocre people." Jack Welch also talks about this in Winning. Companies without a stable and thoughtful hiring plan can easily end up hiring basically the first ones in the door out of necessity for a warm body or the necessity to find the cheapest labor. Likewise, companies without a stable and thoughtful technology strategy can find themselves locked in by past mistakes. Panic sets in and more bad decisions are made. Really, the market conditions snuck up and something that could have been predictable ends up hurting those companies in the long run.
Monday, May 09, 2005
Test styles
Link
I've revisited Rusty Miller's post about various test styles. Cem Kaner's paper is a nice refresher that got me thinking about how we could do so much more with our software testing processes.
The subtle point I take away from Dr. Kaner's paper is that it takes excellent people to drive quality into software. Quality is not a bi-product of a collection of test cases per se.
I think primarily because of a very limited budget, we have relied pretty heavily on dogfooding our products to users through Beta programs. But even with all the money in the world, it's been invaluable getting real users using the product as soon as possible. This is especially true with business process software that is usually highly customized to a company's internal processes. There is no way a bunch of isolated developers is going to get it right. Get something in front of users as soon as possible.
It's certainly a fine line though. Customers can lose faith immediately if they encounter a blocker bug or an excessive amount of significant bugs. I think that's where exceptional expectation setting (hand holding, hugging, donuts, etc.) by your project manager is absolutely critical. It's also a challenge to keep users using the product and providing feedback through constant bug fix cycles. This is especially true if they have alternatives to the software or their daily job functions don't require the use of your product, or simply because they're too busy. Having a formal communication channel like public bug tracking, user groups, or even simply a daily conference call helps this. What you don't want is to ask the question, "who's using our software right now" and not know. The value of a Beta program is diminished nearly completely when this situation becomes reality.
Also, the most common reaction to Beta software is, "it would be really cool if it could do 'x'." Suddenly the project you thought was going to wrap up in a month or two has doubled with remaining work. I think this is where the contract process or statement of work process is so critical. It's nice to fall back on an agreement for the original scope of the project. Obviously you can't think of everything up front so implementing processes that produce shorter code cycles after a release are critical. Its always easier to break it to a client that a feature didn't make it in this release but will be in the next one only four weeks out.
I've revisited Rusty Miller's post about various test styles. Cem Kaner's paper is a nice refresher that got me thinking about how we could do so much more with our software testing processes.
The subtle point I take away from Dr. Kaner's paper is that it takes excellent people to drive quality into software. Quality is not a bi-product of a collection of test cases per se.
I think primarily because of a very limited budget, we have relied pretty heavily on dogfooding our products to users through Beta programs. But even with all the money in the world, it's been invaluable getting real users using the product as soon as possible. This is especially true with business process software that is usually highly customized to a company's internal processes. There is no way a bunch of isolated developers is going to get it right. Get something in front of users as soon as possible.
It's certainly a fine line though. Customers can lose faith immediately if they encounter a blocker bug or an excessive amount of significant bugs. I think that's where exceptional expectation setting (hand holding, hugging, donuts, etc.) by your project manager is absolutely critical. It's also a challenge to keep users using the product and providing feedback through constant bug fix cycles. This is especially true if they have alternatives to the software or their daily job functions don't require the use of your product, or simply because they're too busy. Having a formal communication channel like public bug tracking, user groups, or even simply a daily conference call helps this. What you don't want is to ask the question, "who's using our software right now" and not know. The value of a Beta program is diminished nearly completely when this situation becomes reality.
Also, the most common reaction to Beta software is, "it would be really cool if it could do 'x'." Suddenly the project you thought was going to wrap up in a month or two has doubled with remaining work. I think this is where the contract process or statement of work process is so critical. It's nice to fall back on an agreement for the original scope of the project. Obviously you can't think of everything up front so implementing processes that produce shorter code cycles after a release are critical. Its always easier to break it to a client that a feature didn't make it in this release but will be in the next one only four weeks out.
Sunday, May 08, 2005
Java vs. C# series: Productivity, pt. 1
Advantage: C# .NET
I want to start my series with the main reason why I was ever exposed to C# .NET in the first place - frustration with how long it took to implement J2EE solutions. The interesting thing to note here is that we as developers weren't necessarily frustrated but our managers and President were. I'd also like to add that I was very skeptical that we would be more productive in C# .NET and actually a little resentful that our managers considered the technology to be the main barrier to shorter cycles and not the very complex problem domain. Frankly, going in I was looking for reasons why it was worse to work with C# .NET than Java.
Productivity can be such a nuanced term. We didn't come up with a way to truly measure our productivity after a year - more like I know it when I see it... And after a full year working with another critical thinking Java developer on the project, I think we're both surprised at how quick we are to say that we are indeed more productive in C# .NET.
Interestingly, Rod Johnson discusses this very issue in his new book Expert One-on-One J2EE Development without EJB. However, our case was subtly different than the architecture issues that he discusses. In fact, we've implemented areas of our application to utilize Spring, message driven beans, web services, etc. In our case we were specifically looking for more bang on the client-side.
It may not be completely fair to compare C# WinForms to working with JSP. There are so many obvious issues ("our clients run Linux", etc.) that I won't go into them - I will say that we are afforded some solid assumptions with our customers' systems and policies. I came from JSP where I spent *years* bending over backwards with dynamic HTML and JavaScript to bring our UIs to just within "tolerable" by our customers' standards. And I think we've done some pretty amazing things. But it was sooo nice writing object oriented client-side code that actually runs very nicely on our customers' machines.
Productivity gains with client-side C#:
I want to start my series with the main reason why I was ever exposed to C# .NET in the first place - frustration with how long it took to implement J2EE solutions. The interesting thing to note here is that we as developers weren't necessarily frustrated but our managers and President were. I'd also like to add that I was very skeptical that we would be more productive in C# .NET and actually a little resentful that our managers considered the technology to be the main barrier to shorter cycles and not the very complex problem domain. Frankly, going in I was looking for reasons why it was worse to work with C# .NET than Java.
Productivity can be such a nuanced term. We didn't come up with a way to truly measure our productivity after a year - more like I know it when I see it... And after a full year working with another critical thinking Java developer on the project, I think we're both surprised at how quick we are to say that we are indeed more productive in C# .NET.
Interestingly, Rod Johnson discusses this very issue in his new book Expert One-on-One J2EE Development without EJB. However, our case was subtly different than the architecture issues that he discusses. In fact, we've implemented areas of our application to utilize Spring, message driven beans, web services, etc. In our case we were specifically looking for more bang on the client-side.
It may not be completely fair to compare C# WinForms to working with JSP. There are so many obvious issues ("our clients run Linux", etc.) that I won't go into them - I will say that we are afforded some solid assumptions with our customers' systems and policies. I came from JSP where I spent *years* bending over backwards with dynamic HTML and JavaScript to bring our UIs to just within "tolerable" by our customers' standards. And I think we've done some pretty amazing things. But it was sooo nice writing object oriented client-side code that actually runs very nicely on our customers' machines.
Productivity gains with client-side C#:
- Extremely rapid application design, feedback, and turnaround time on the UI.
- Able to create extremely rich user interfaces.
- Object oriented client-side code that runs optimally on Windows.
- Unit Testable client-side code.
- Good WYSIWYG IDE with solid debugger and auto-code-completion.
- Excellent integration with xml and web services.
- Easy to transition from Java to C#.
- Quicker, more confident code cycles (1. & 4.) meant more focus on the problem domain.
Subscribe to:
Posts (Atom)
