A few posts back, I discussed offshoring, and I mentioned that one of the big things standing in the way of American companies when they try to hire in India is the relative volume of applicants. Browsing Google's gmail feeds I found this article, which details the problem confronting Inidan hiring - the sheer volume of people they have to process in the short times. It also notes that there is an impending skills shortage there. All this is good news for teh American IT/software market - as offshore talent gets scarce, their salaries rise, and it becomes less effective to move the jobs away.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, April 09, 2006
Wednesday, March 29, 2006
Are Geeks Countercultural?
It's hard to be a real geek these days.
Online gaming is almost mainstream; everyone is hooking up through MySpace or some other similar website; collaborative sites like Flickr abound; everyone has email.
Even geek fashion is everywhere - between the 70's revival and Napolean Dynamite, plaid is scarce.
During the dot-com boom, computer people were trendy and popular, and everyone wanted to be a webmaster. We're still in the halo from that time.
So geek culture is slowly inching its way into the mainstream, but from a flanking angle.
We're not yet totally accepted, but we're no longer pariahs. The schoolkids are still vulnerable to Lord Of The Flies scenarios, but less so after Columbine.
The downside is that with this explosion of mainline geekiness there is a greater capability for the less-geeky to better harass those they dislike. Online bullying is almost trivially easy, and the posting of embarassing photos to websites can draw volumes of ridicule from across the nation.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Online gaming is almost mainstream; everyone is hooking up through MySpace or some other similar website; collaborative sites like Flickr abound; everyone has email.
Even geek fashion is everywhere - between the 70's revival and Napolean Dynamite, plaid is scarce.
During the dot-com boom, computer people were trendy and popular, and everyone wanted to be a webmaster. We're still in the halo from that time.
So geek culture is slowly inching its way into the mainstream, but from a flanking angle.
We're not yet totally accepted, but we're no longer pariahs. The schoolkids are still vulnerable to Lord Of The Flies scenarios, but less so after Columbine.
The downside is that with this explosion of mainline geekiness there is a greater capability for the less-geeky to better harass those they dislike. Online bullying is almost trivially easy, and the posting of embarassing photos to websites can draw volumes of ridicule from across the nation.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 22, 2006
I'm Baaa-ack!
Apologies, Dear Readers (all 3 of you), for the long delay. My employer was busy being bought out by a larger company, so I was distracted by much reality.
The purchase process was interesting in a cynical way. There was a great deal of enthusiasm from the buyers about how great it was that the two companies were combining - too much enthusiasm. My cow-orkers and I began to make Jonestown and Heaven's Gate references. There was much reference to "synergy" and "Actualization".
All this has fed several ideas for later columns.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The purchase process was interesting in a cynical way. There was a great deal of enthusiasm from the buyers about how great it was that the two companies were combining - too much enthusiasm. My cow-orkers and I began to make Jonestown and Heaven's Gate references. There was much reference to "synergy" and "Actualization".
All this has fed several ideas for later columns.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 12, 2006
Automation, a developer's best friend
This is not going to be a big post, but I definitely wanted to push automation as a Good Thing.
You don't need to go whole hog, with an expensive framework supporting email and IM's the build admin when things go wrong. Shell scripts, SQL, and text files will do.
Automate your builds, so you can build any part of your system with a single command.
Automate you build notifications, so the build admin can be aware of errors ASAP, and notify your developers.
Automate your regression tests, so you can make sure you don't lose anything when you add new features.
If you are fortunate enough to have management that supports agile development, automate your new feature tests so you can confirm correct function of the new stuff.
Where possible, make your GUIs build automatically from text-based description files, so you can enable/disable features without requiring code changes.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
You don't need to go whole hog, with an expensive framework supporting email and IM's the build admin when things go wrong. Shell scripts, SQL, and text files will do.
Automate your builds, so you can build any part of your system with a single command.
Automate you build notifications, so the build admin can be aware of errors ASAP, and notify your developers.
Automate your regression tests, so you can make sure you don't lose anything when you add new features.
If you are fortunate enough to have management that supports agile development, automate your new feature tests so you can confirm correct function of the new stuff.
Where possible, make your GUIs build automatically from text-based description files, so you can enable/disable features without requiring code changes.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Thursday, March 02, 2006
There's never just one release
One of the biggest issues that I've had career-wise has been the even distribution of new development work with support work. One of my past jobs, I ended up spending all my time supporting the released products, and no time developing the new products. This caused problems because the support effort was not well-regarded - it wasn't the sexy new stuff that fired everyone's imaginations. I got quite fed up about it, so it's now one of my discussion points at interviews and reviews.
So when you planning software products, be aware that someone will have to be the support team, and they either have to like the job, or you'll have to have a rotation between the people to prevent burnout.
Support duty is hard for many developers, both from the technical side and the glamor side. Some of the difficulties are:
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
So when you planning software products, be aware that someone will have to be the support team, and they either have to like the job, or you'll have to have a rotation between the people to prevent burnout.
Support duty is hard for many developers, both from the technical side and the glamor side. Some of the difficulties are:
- It's difficult to keep answering the same questions time and again from the different customers that run across an issue.
- It's difficult to see where a customer is having a problem when you know the code well - you expect things to go as you designed them, and not as the user does them.
- you have to make the quick fix, because the customer can't wait long for a solution.
- you don't get to exercise your design muscles because the product is released, and nobody will want to rework it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Friday, February 24, 2006
The Obligatory Hacker Culture Post
Ok, so I'm predictible.
As someone who discovered computers just about the time the idea of the PC was reaching the market, I'm one of those who has been fully immersed in the hacking culture. I never was as hardcore as the guys who wardialed the Pentagon, or build my own computer from NAND gates, but I got my PC as soon as I got out of college, and have been programming in some form for almost 30 years.
For me, the defining hacker trait is curiousity. You want to know how something works, or want to build one for yourself. It manifests most strongly in computers, I think, because software is so malleable that once you've bought the computer and get a compiler/interpreter, you can make nearly anything. In contrast, electrical engineering hacking requires you to buy parts, which limits your work. It's also much easier to prototype in software than in hardware, and you almost never blow up parts in the testing.
At the present time, it's a sad truth that the US is drifting away from the hacking spirit. The advent of offshoring has made software a precarious career, and colleges are starting to move their curricula away from the fundamentals of software. So many of our products are packaged so that there are no repairable parts in them. But a few rays of hope are shining - Make is publicizing hacks, and the very flood of disposable technology is spurring hackers to try things, since they are so cheap to buy.
I hope the trend picks up speed. I'm looking forward to some of the cool things lurking around in people's skulls.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
As someone who discovered computers just about the time the idea of the PC was reaching the market, I'm one of those who has been fully immersed in the hacking culture. I never was as hardcore as the guys who wardialed the Pentagon, or build my own computer from NAND gates, but I got my PC as soon as I got out of college, and have been programming in some form for almost 30 years.
For me, the defining hacker trait is curiousity. You want to know how something works, or want to build one for yourself. It manifests most strongly in computers, I think, because software is so malleable that once you've bought the computer and get a compiler/interpreter, you can make nearly anything. In contrast, electrical engineering hacking requires you to buy parts, which limits your work. It's also much easier to prototype in software than in hardware, and you almost never blow up parts in the testing.
At the present time, it's a sad truth that the US is drifting away from the hacking spirit. The advent of offshoring has made software a precarious career, and colleges are starting to move their curricula away from the fundamentals of software. So many of our products are packaged so that there are no repairable parts in them. But a few rays of hope are shining - Make is publicizing hacks, and the very flood of disposable technology is spurring hackers to try things, since they are so cheap to buy.
I hope the trend picks up speed. I'm looking forward to some of the cool things lurking around in people's skulls.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Tuesday, February 21, 2006
Software Tools
These days there are a great many tools that developers can use to create software. There is UML and the various products that use it. The Java world has Struts and its successors for application development. Ruby on Rails is currently enjoying popularity as a web application development platform.
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Subscribe to:
Posts (Atom)