Stanford on iTunes - subscribed!
BTW, it seems as if the latest iTunes 6.0.2 client for Windows solves that annoying flickering-when-dragging-the-scrollbar-bubble-issue - just in case someone encountered the same problem.
Update: I had rejoiced too soon - flickering still happens... :-(
Friday, January 27, 2006
Monday, January 23, 2006
JetBrains ReSharper
If you - just like me - are in the unfortunate situation that you cannot migrate all your Visual Studio 2003 projects to Visual Studio 2005 yet, and grow increasingly jealous about those cool new VS 2005 productivity enhancements like improved IntelliSense, refactoring or code snippets, there is a remedy: JetBrains ReSharper. It comes equipped with a rich set of features, such as intelligent coding assistance, on-the-fly error highlighting and quick error correction, support for code refactoring, and a whole lot more. We have been using it under VS 2003 for a while, and it has saved us tons of time.
Disclaimer: I am by no means affiliated with JetBrains.
Disclaimer: I am by no means affiliated with JetBrains.
Wednesday, January 18, 2006
Spamusement
Poorly-drawn cartoons inspired by actual spam subject lines.
Thursday, January 12, 2006
The Perils Of JavaSchools
Just a little follow-up to my posting about Joel Spolsky's "The Perils Of JavaSchools". Please don't get me wrong, I enjoy very much coding in Java (even more than in C#), my only point was (and also Joel's, I think) that students who have been taught programming solely in Java are missing some important concepts about how things work under the hoods. And the knowledge about how lower-level stuff is being done is very important in order to be able to build high-quality software systems on other platforms, such as C or C++. Just learning a new language syntax will not be sufficient in those cases.
.NET User Group Upperaustria
I figured out a little bit too late that the "Upperaustrian .NET User Group" has been formed already back in November. Next week Tuesday their third meeting will take place at the University of Linz, including a presentation about "ASP.NET 2.0 and Web Parts". Definitely a good reason to go there and check it out.
Sunday, January 08, 2006
Friday, January 06, 2006
Startup Or Corporate Group?
Which place is more likely to bring out the best in talented and motivated developers, small startups or large corporate groups? Well, it's a double-edged sword.
Usually at startups, the environment is more challenging. Stakes are high, but so can be the gains. No politics, no messing around, just one mutual goal. There is no place for dorks to hide. They are either not hired at all, or identified within days. A great working experience if the right kind of people get together. But then still nine out of ten startups fail (the number varies depending on the definition of "failure"), so it's quite likely that all those efforts are lost.
With big companies, this is less likely to happen. Heck, they even back doomed projects for years. This doesn't necessary imply that they are going support a winner project accordingly either, but at least it increases the chances they will. Unfortunately working in large companies can be cumbersome, especially for the more gifted employees. Committees that are unable to make decisions, projects stuck in the conceptual stage for years, proteges and "know-it-alls" meddling with your venture, and if there is no management buy-in, you are going to fail no matter how hard you try.
So what's the best place to work at? It might be a combination of both. A startup-like department or subsidiary inside a large organization. That alone is not enough, you have to be able to attract highly-qualified people, your management has to trust you and give you the time you need, and of course you still have get the job done. Then this is a likely scenario for joy of work and project success.
Usually at startups, the environment is more challenging. Stakes are high, but so can be the gains. No politics, no messing around, just one mutual goal. There is no place for dorks to hide. They are either not hired at all, or identified within days. A great working experience if the right kind of people get together. But then still nine out of ten startups fail (the number varies depending on the definition of "failure"), so it's quite likely that all those efforts are lost.
With big companies, this is less likely to happen. Heck, they even back doomed projects for years. This doesn't necessary imply that they are going support a winner project accordingly either, but at least it increases the chances they will. Unfortunately working in large companies can be cumbersome, especially for the more gifted employees. Committees that are unable to make decisions, projects stuck in the conceptual stage for years, proteges and "know-it-alls" meddling with your venture, and if there is no management buy-in, you are going to fail no matter how hard you try.
So what's the best place to work at? It might be a combination of both. A startup-like department or subsidiary inside a large organization. That alone is not enough, you have to be able to attract highly-qualified people, your management has to trust you and give you the time you need, and of course you still have get the job done. Then this is a likely scenario for joy of work and project success.
Sunday, January 01, 2006
Ineffective Development Practices
Via Günter Obiltschnig's Weblog: Steve McConnell lists 36 ineffective development practices in his classic book "Rapid Development" (I certainly got a copy of "Rapid Development" on my bookshelf, just like "Code Complete" and "Software Project Survival Guide")
People-Related Mistakes
#1: Undermined motivation
#2: Weak personnel
#3: Uncontrolled problem employees
#4: Heroics
#5: Adding people to a late project
#6: Noisy, crowded offices
#7: Friction between developers and customers
#8: Unrealistic expectations
#9: Lack of effective project sponsorship
#10: Lack of stakeholder buy-in
#11: Lack of user input
#12: Politics placed over substance
#13: Wishful thinking
Process-Related Mistakes
#14: Overly optimistic schedules
#15: Insufficient risk management
#16: Contractor failure
#17: Insufficient planning
#18: Abandonment of planning under pressure
#19: Wasted time during the fuzzy front end
#20: Shortchanged upstream activities
#21: Inadequate design
#22: Shortchanged quality assurance
#23: Insufficient management controls
#24: Premature or too frequent convergence
#25: Omitting necessary tasks from estimates
#26: Planning to catch up later
#27: Code-like-hell programming
Product-Related Mistakes
#28: Requirements gold-plating
#29: Feature creep
#30: Developer gold-plating
#31: Push me, pull me negotiation
#32: Research-oriented development
Technology-Related Mistakes
#33: Silver-bullet syndrome
#34: Overestimated savings from new tools or methods
#35: Switching tools in the middle of a project
#36: Lack of automated source-code control
People-Related Mistakes
#1: Undermined motivation
#2: Weak personnel
#3: Uncontrolled problem employees
#4: Heroics
#5: Adding people to a late project
#6: Noisy, crowded offices
#7: Friction between developers and customers
#8: Unrealistic expectations
#9: Lack of effective project sponsorship
#10: Lack of stakeholder buy-in
#11: Lack of user input
#12: Politics placed over substance
#13: Wishful thinking
Process-Related Mistakes
#14: Overly optimistic schedules
#15: Insufficient risk management
#16: Contractor failure
#17: Insufficient planning
#18: Abandonment of planning under pressure
#19: Wasted time during the fuzzy front end
#20: Shortchanged upstream activities
#21: Inadequate design
#22: Shortchanged quality assurance
#23: Insufficient management controls
#24: Premature or too frequent convergence
#25: Omitting necessary tasks from estimates
#26: Planning to catch up later
#27: Code-like-hell programming
Product-Related Mistakes
#28: Requirements gold-plating
#29: Feature creep
#30: Developer gold-plating
#31: Push me, pull me negotiation
#32: Research-oriented development
Technology-Related Mistakes
#33: Silver-bullet syndrome
#34: Overestimated savings from new tools or methods
#35: Switching tools in the middle of a project
#36: Lack of automated source-code control
Subscribe to:
Posts (Atom)