I've blogged about the current global recession's affect on innovation before. I have blogged many times about the waxing and waning of virtual worlds technology called Second Life. Now, I get to blog about both subjects simultaneously.
I recently attended a presentation in Second Life by Gene Leganza of Forrester Research, Inc called Six Trends for Enterprise Architecture Professionals in 2009. This presentation was held at a meeting space on Second Life owned and operated by a small business development networking brokerage firm called Unique Customer Service Approach International. It looked a lot like a proper lecture hall with some virtual world style embellishments like giant, floating question marks that you click on when you want to ask a question. The speaker used voice chat but you could use the Second Life Instant Messaging feature to ask questions. You also had to click on your chair to cause your SL avatar to clap.
The talk itself was very informative and well thought out. I have blogged elsewhere on the actual content of the presentation but the upshot is this. Times are tough so you Enterprise Architects out there need to actually start doing what you were originally hired to do which was to deliver software development process, methodology, and architecture that is optimized at increasing long term shareholder value. Please excuse my attitude but I am passionate on the subject.
Showing posts with label software development. Show all posts
Showing posts with label software development. Show all posts
Thursday, January 15, 2009
Tuesday, October 7, 2008
jQuery and Microsoft
Technology is to software architects what stock is to traders. You are constantly on the lookout for changes in the marketplace to take advantage of an under valued but rising offering. What's that old cliché? Buy on rumor and sell on news.
You would had to have been in a coma for the past decade to have missed AJAX which is an approach to writing web applications that mitigates the disorienting page refresh of the server round-trip by having the page get the new data through a Java script call instead of reloading. To a coder, the heart of AJAX is the XmlHttpRequest object. There are lots of Java script libraries out there that abstract away the web browser differences in using this object, thus simplifying your Java script.
jQuery is one of those libraries. It competes with lots of different offerings such as Prototype, YUI, MooTools, and Dogo. Yesterday, jQuery got mentioned in a rumor that is sure to boost perception of its value over its competitors. On a promotional blog site owned by Microsoft, it was announced that Microsoft is adopting and supporting jQuery in its ASP.NET AJAX components and integrating support of jQuery in its flagship IDE VS.NET
Why does it really matter which technology to choose? After all, each and every technology mentioned here does a great job of doing AJAX. From a technology perspective, you can't go wrong; however, there are more aspects to choosing a software architecture than technology.
A smoother developer experience should accelerate the implementation phase of any project. So, with this announcement, jQuery becomes a more compelling choice for Microsoft development shops. In any work environment, you have to think about turn-around. How long does it take to replace an employee who is leaving? That means being competitive with other shops on a lot of things including pay, benefits, and how desirable your technology is. Using popular technology makes it just a little bit easier to attract and hire good candidates. Popular technology can also be a compelling sell to your customers whose I.T. departments might want to evaluate what technology you use.
You would had to have been in a coma for the past decade to have missed AJAX which is an approach to writing web applications that mitigates the disorienting page refresh of the server round-trip by having the page get the new data through a Java script call instead of reloading. To a coder, the heart of AJAX is the XmlHttpRequest object. There are lots of Java script libraries out there that abstract away the web browser differences in using this object, thus simplifying your Java script.
jQuery is one of those libraries. It competes with lots of different offerings such as Prototype, YUI, MooTools, and Dogo. Yesterday, jQuery got mentioned in a rumor that is sure to boost perception of its value over its competitors. On a promotional blog site owned by Microsoft, it was announced that Microsoft is adopting and supporting jQuery in its ASP.NET AJAX components and integrating support of jQuery in its flagship IDE VS.NET
Why does it really matter which technology to choose? After all, each and every technology mentioned here does a great job of doing AJAX. From a technology perspective, you can't go wrong; however, there are more aspects to choosing a software architecture than technology.
A smoother developer experience should accelerate the implementation phase of any project. So, with this announcement, jQuery becomes a more compelling choice for Microsoft development shops. In any work environment, you have to think about turn-around. How long does it take to replace an employee who is leaving? That means being competitive with other shops on a lot of things including pay, benefits, and how desirable your technology is. Using popular technology makes it just a little bit easier to attract and hire good candidates. Popular technology can also be a compelling sell to your customers whose I.T. departments might want to evaluate what technology you use.
Friday, September 26, 2008
The Bane of Every Coder
I am an advocate of developer documentation. I understand why smaller, less mature ISVs and IT shops would take the quick and dirty shortcut of forgoing developer documentation. No one wants to do it. It costs money keeping that documentation up to date. Programmers should get paid to write code. Blah, blah, blah.
Larger, more mature, shops should know better. They should realize that the total cost of maintaining large systems, over time, is much less when new developers can accelerate their time to productivity by reading some well written, accurate developer documentation. Also, it's nice to throw the developer documentation at the powers that be (i.e. government, acquiring company, BOD) when they want to know what's really going on. I'll bet that Microsoft wished that they had spent some more resources on writing good developer documentation.
You don't like to do it. I don't like to do it. Nobody likes to do it. But writing quality developer documentation is like filing your taxes. Doing it is better than suffering the long term consequences of not doing it.
Larger, more mature, shops should know better. They should realize that the total cost of maintaining large systems, over time, is much less when new developers can accelerate their time to productivity by reading some well written, accurate developer documentation. Also, it's nice to throw the developer documentation at the powers that be (i.e. government, acquiring company, BOD) when they want to know what's really going on. I'll bet that Microsoft wished that they had spent some more resources on writing good developer documentation.
You don't like to do it. I don't like to do it. Nobody likes to do it. But writing quality developer documentation is like filing your taxes. Doing it is better than suffering the long term consequences of not doing it.
Sunday, June 29, 2008
The Rewrite Game
While drinking my morning cappuccino, I ran across this opinion piece on page 4 of the business section in the Sunday edition of the New York Times. Basically, the author is asking Microsoft to rewrite their operating system completely from scratch instead of continuing to enhance it as they have done for decades. He uses Apple as an example of this. They did a complete rewrite of their operating system when they moved from version 9.8 to 10. This is not the first time that an Apple advocate has publicly called on Microsoft to rewrite their operating system.
Why is this noteworthy? Anyone who has written software for public consumption will eventually be faced with the very hard question of whether or not it is time to rewrite. As you enhance or fix software, every change makes the software a little bit more brittle. Over time, this raises the cost of maintaining software. This is really not that much different from the car buying decision. You buy a new car and for years it just runs and all you have to do is normal maintenance stuff like oil and tire changes. As the car gets older, it starts to break down more and more. Eventually, you realize that you are paying more in repair bills than what a car note would be.
Why hasn't Microsoft rewritten their operating system? Because it is too expensive. It has been theorized that Vista has over fifty million lines of code. Think about that number for a minute. You would have to have already celebrated your 95th birthday in order to have lived that many minutes. It takes a lot more than a minute to write a line of code, especially when you are talking about operating system code. Time, mind, and money spent to rewrite what they already have is time, mind, and money not spent on entering all these markets that Microsoft so ambitiously wants to enter in. Google would like nothing more than for Microsoft to rewrite their operating system.
How did Apple do it? They didn't worry about backwards compatibility. If you bought a software product for Macintosh version 9.8, then it would not work on OS X. You would have to make another software purchase just to get the same functionality on the new operating system. Apparently, IPod hugging kids with strange facial hair are more willing to part with their hard earned cash than those pudgy business suit types who just might take their unhappiness to a more litigious level.
Why does backwards compatibility make the rewrite so much more expensive? Well, for one thing, Apple didn't really rewrite OS X from scratch. They took their work on Next Gen and BSD and started from that. Microsoft doesn't have that luxury.
Will Microsoft ever rewrite their operating system? Who can ever say? They do rewrite parts of it from time to time. Also, they really have two operating systems now, one for servers and the other for workstations. Nobody, that I know of, ever really complains about the server OS which I believe to be more strategic for the company over the long haul. It's probably easier and more in line with their long term objectives to relinquish the workstation market to the Apples and the Linuxes of the world than to rewrite Vista.
Why is this noteworthy? Anyone who has written software for public consumption will eventually be faced with the very hard question of whether or not it is time to rewrite. As you enhance or fix software, every change makes the software a little bit more brittle. Over time, this raises the cost of maintaining software. This is really not that much different from the car buying decision. You buy a new car and for years it just runs and all you have to do is normal maintenance stuff like oil and tire changes. As the car gets older, it starts to break down more and more. Eventually, you realize that you are paying more in repair bills than what a car note would be.
Why hasn't Microsoft rewritten their operating system? Because it is too expensive. It has been theorized that Vista has over fifty million lines of code. Think about that number for a minute. You would have to have already celebrated your 95th birthday in order to have lived that many minutes. It takes a lot more than a minute to write a line of code, especially when you are talking about operating system code. Time, mind, and money spent to rewrite what they already have is time, mind, and money not spent on entering all these markets that Microsoft so ambitiously wants to enter in. Google would like nothing more than for Microsoft to rewrite their operating system.
How did Apple do it? They didn't worry about backwards compatibility. If you bought a software product for Macintosh version 9.8, then it would not work on OS X. You would have to make another software purchase just to get the same functionality on the new operating system. Apparently, IPod hugging kids with strange facial hair are more willing to part with their hard earned cash than those pudgy business suit types who just might take their unhappiness to a more litigious level.
Why does backwards compatibility make the rewrite so much more expensive? Well, for one thing, Apple didn't really rewrite OS X from scratch. They took their work on Next Gen and BSD and started from that. Microsoft doesn't have that luxury.
Will Microsoft ever rewrite their operating system? Who can ever say? They do rewrite parts of it from time to time. Also, they really have two operating systems now, one for servers and the other for workstations. Nobody, that I know of, ever really complains about the server OS which I believe to be more strategic for the company over the long haul. It's probably easier and more in line with their long term objectives to relinquish the workstation market to the Apples and the Linuxes of the world than to rewrite Vista.
Wednesday, April 30, 2008
Why Johnny Coder Doesn't Read
I ran across a blog post today about how most software developers don't read. This is noteworthy because the technology for writing software innovates at a very high rate. How can today's coders keep up if they don't read about new technology? The article conflicts itself about whether or not developers learn about new technology online instead of through books. The major reason given as to why coders don't read books is the lack of quality in the content of the books being published. The author then gives some recommendations for books that he believes coders should read.
I totally agree on the quality issue. Most books on writing software simply stink. They are all about screen shots and "click here, type this" descriptions from the lowest paid geek that the publishing house can find. There are some good books out there written by quality writers but they are in the minority.
Quality isn't the only reason why coders don't read books. Economics is another. The fast pace of innovation dramatically reduces the shelf life of most books on programming that are specific to a particular technology. Microsoft produces a major release of .NET about once every year. Sun Microsystems releases a major release of Java about every two years. The corresponding after market books go for $50 to $75 (USD) a pop. Add to that the fact that the project you are working on most probably won't be able to upgrade to the new version and you quickly find yourself coming to the conclusion that purchasing these books don't have a good ROI.
Another reason why programming books aren't being read by coders is learning modality. Everyone has different experiences which affect how they learn. So, everyone learns differently. What order that facts are presented in a teaching environment affects learning efficacy on a per student basis. Books can't change the order that facts are presented but web sites can because the reader interacts with the content in his or her navigation choices. Obviously, the traditional classroom setting is also sufficiently interactive enough such that a good teacher can get the message across to his motivated students effectively.
I totally agree with the author's book recommendations. Those are some great books to read. You will be a better coder for reading them. In addition to these, permit me to recommend a few more. You may not be a C coder but do read Kernighan and Pike's The Practice of Programming which gives you a great taste for the craft of writing quality code. Most business level development these days is object oriented. If you do anything even similar to object oriented programming, then you owe it to yourself and your employer to read Design Patterns by Gamma, Helm, Johnson, and Vlissides (a.k.a GoF). These two books have a very long shelf life.
Why don't I recommend more books than these? Because, like I said before, people are different. Different strokes for different folks. The book that really does it for me may not work for you. So, get thee to the bookstore (physical or virtual) and leaf through what is available. Look at the writer's style. Pick a topic of interest from the table of contents and read the introductory paragraph. Rinse and repeat until you find the book that you feel is the most lucid and educational for you.
You may be unclear as to what topics that you should be reading about. Well, most modern business application developers should be interested in data access. It is very likely that you will be coding web applications so you should be quite hip to the following standards; HTTP, HTML, SOAP, and CSS. Another interesting platform neutral topic is AOP.
As far as platform specific reading, again, find the right book for you. Looking over my own bookshelf, I can't help but notice the following publishers keep appearing over and over again; O'Reilly, Addison Wesley, Apress, and Prentice Hall Professional. Not a lot here from Wrox or SAMS to be honest. I'm on the fence with IDG, Manning and McGraw Hill. I only have two books from New Riders but they are both good.
Software architects need to go the extra distance to read about competing platforms. Why? How can you make the right choice if you aren't aware of the alternatives? If you don't like to read, then don't become a software architect. Go here for a good list of buzzwords to start your reading list with.
I totally agree on the quality issue. Most books on writing software simply stink. They are all about screen shots and "click here, type this" descriptions from the lowest paid geek that the publishing house can find. There are some good books out there written by quality writers but they are in the minority.
Quality isn't the only reason why coders don't read books. Economics is another. The fast pace of innovation dramatically reduces the shelf life of most books on programming that are specific to a particular technology. Microsoft produces a major release of .NET about once every year. Sun Microsystems releases a major release of Java about every two years. The corresponding after market books go for $50 to $75 (USD) a pop. Add to that the fact that the project you are working on most probably won't be able to upgrade to the new version and you quickly find yourself coming to the conclusion that purchasing these books don't have a good ROI.
Another reason why programming books aren't being read by coders is learning modality. Everyone has different experiences which affect how they learn. So, everyone learns differently. What order that facts are presented in a teaching environment affects learning efficacy on a per student basis. Books can't change the order that facts are presented but web sites can because the reader interacts with the content in his or her navigation choices. Obviously, the traditional classroom setting is also sufficiently interactive enough such that a good teacher can get the message across to his motivated students effectively.
I totally agree with the author's book recommendations. Those are some great books to read. You will be a better coder for reading them. In addition to these, permit me to recommend a few more. You may not be a C coder but do read Kernighan and Pike's The Practice of Programming which gives you a great taste for the craft of writing quality code. Most business level development these days is object oriented. If you do anything even similar to object oriented programming, then you owe it to yourself and your employer to read Design Patterns by Gamma, Helm, Johnson, and Vlissides (a.k.a GoF). These two books have a very long shelf life.
Why don't I recommend more books than these? Because, like I said before, people are different. Different strokes for different folks. The book that really does it for me may not work for you. So, get thee to the bookstore (physical or virtual) and leaf through what is available. Look at the writer's style. Pick a topic of interest from the table of contents and read the introductory paragraph. Rinse and repeat until you find the book that you feel is the most lucid and educational for you.
You may be unclear as to what topics that you should be reading about. Well, most modern business application developers should be interested in data access. It is very likely that you will be coding web applications so you should be quite hip to the following standards; HTTP, HTML, SOAP, and CSS. Another interesting platform neutral topic is AOP.
As far as platform specific reading, again, find the right book for you. Looking over my own bookshelf, I can't help but notice the following publishers keep appearing over and over again; O'Reilly, Addison Wesley, Apress, and Prentice Hall Professional. Not a lot here from Wrox or SAMS to be honest. I'm on the fence with IDG, Manning and McGraw Hill. I only have two books from New Riders but they are both good.
Software architects need to go the extra distance to read about competing platforms. Why? How can you make the right choice if you aren't aware of the alternatives? If you don't like to read, then don't become a software architect. Go here for a good list of buzzwords to start your reading list with.
Monday, March 24, 2008
Yet Another Culture War Rant on the Internet
I normally don't comment on the rants of Robert Cringely because I find his rhetoric to be too "over the top" manipulative for my tastes.
However, a recent piece of his, entitled War of the Worlds: The Human Side of Moore's Law motivated me to blog about it here.
Not that I actually agree with his main premise which is that the Internet is going to replace primary education. It's not going to replace schools anymore than it replaced any of the other institutions that pundits have predicted it would replace including newspapers, television, or the family unit. It has and will, however, supplement, augment, and transform all of those institutions.
My experience working with offshore software development houses and in discussions with my peers in academia regarding distance learning lead me to the conclusion that the Internet cannot replace the psychological need to relate to humans in close physical proximity no matter how much money is saved by not having to have everyone together in the same room.
The Internet can, however, reduce these location driven costs because you can have a very effective group even when everyone isn't in the same room all of the time. They need to get together to meet periodically. They need to hang out a little bit. Then they can go back home and continue to work together over the Internet. Productivity can be higher than when they never physically meet at all.
What is your opinion? Are we "under attack" in some kind of culture war or is this just the next phase in human development?
However, a recent piece of his, entitled War of the Worlds: The Human Side of Moore's Law motivated me to blog about it here.
Not that I actually agree with his main premise which is that the Internet is going to replace primary education. It's not going to replace schools anymore than it replaced any of the other institutions that pundits have predicted it would replace including newspapers, television, or the family unit. It has and will, however, supplement, augment, and transform all of those institutions.
My experience working with offshore software development houses and in discussions with my peers in academia regarding distance learning lead me to the conclusion that the Internet cannot replace the psychological need to relate to humans in close physical proximity no matter how much money is saved by not having to have everyone together in the same room.
The Internet can, however, reduce these location driven costs because you can have a very effective group even when everyone isn't in the same room all of the time. They need to get together to meet periodically. They need to hang out a little bit. Then they can go back home and continue to work together over the Internet. Productivity can be higher than when they never physically meet at all.
What is your opinion? Are we "under attack" in some kind of culture war or is this just the next phase in human development?
Saturday, March 22, 2008
Cell Phones and the World Wide Wireless Web
I recently ran across an article on the Ten Most Disruptive Technology Combinations which included the combination of cell phones and wireless internet access as the number one combination. The article mentions how this convergence blurs the lines between work and play and that is forcing telecom monopolies to open up their networks.
Within the past year, I upgraded my cell phone which included an Internet package. I thought that I would cancel the package pretty soon but I am still willing to pay $20 per month per phone for the privilege of unlimited web and email. I must admit that this is a compelling technology.
So, compelling that I added a mobile edition to my online publication about what affects that technology and the media have on culture.
Authoring web pages for mobile devices is sort of a Back to the Future experience for me. It's all about a small download to a device with limited interactive capabilities. The version of HTML is hyper modern but there are a lot of elements that you cannot or should not use including script, tables, and images. You should also limit links to the navigation within your site.
Summer Update: I have started a new technology company which also includes a mobile edition.
Within the past year, I upgraded my cell phone which included an Internet package. I thought that I would cancel the package pretty soon but I am still willing to pay $20 per month per phone for the privilege of unlimited web and email. I must admit that this is a compelling technology.
So, compelling that I added a mobile edition to my online publication about what affects that technology and the media have on culture.
Authoring web pages for mobile devices is sort of a Back to the Future experience for me. It's all about a small download to a device with limited interactive capabilities. The version of HTML is hyper modern but there are a lot of elements that you cannot or should not use including script, tables, and images. You should also limit links to the navigation within your site.
Summer Update: I have started a new technology company which also includes a mobile edition.
Friday, March 7, 2008
Metcalfe's Law
A friend of mine recently emailed me this announcement with the comment "use this with idea and get rich." Although the announcement of an iPhone SDK is new, this is not a new trend. Companies such as Facebook, Google, and Yahoo have all signed up to a degree to the following model.
- Technology company reinvents itself as a technology platform company.
- Productizes its application tier with a public facing API.
- Markets to developers encouraging them to consume their API and "get rich."
- Takes advantage of subsequent buzz to build brand.
Friday, February 29, 2008
The Art of Project Design
I recently ran across this blog entry on the art of project design. As a longtime director of software development, I believe it to have some very sound advice.
This blogger discourages the use of MS-Project. I am not a big fan of MS-Project either. The biggest reason why I avoid MS-Project is the differentiation of planned versus actual and the fact that an event that is completely out of the control of the end user, namely the passing of time, is what triggers the change in status from planned to actual. Once a task begins, your options of editing it become severely limited.
This blogger uses MS-Excel instead to create his project plans. I prefer GanttProject. I tried Open Workbench recently but was not a fan, primarily because it lacked support for a task hierarchy.
But that wasn't the most important advice from this blogger. Much more important is his admonitions to focus on features and not phases, to build the best features first, to deliver every two months, and to collaborate with your business partner. I gave some very similar advice recently in one of my own posts.
This blogger discourages the use of MS-Project. I am not a big fan of MS-Project either. The biggest reason why I avoid MS-Project is the differentiation of planned versus actual and the fact that an event that is completely out of the control of the end user, namely the passing of time, is what triggers the change in status from planned to actual. Once a task begins, your options of editing it become severely limited.
This blogger uses MS-Excel instead to create his project plans. I prefer GanttProject. I tried Open Workbench recently but was not a fan, primarily because it lacked support for a task hierarchy.
But that wasn't the most important advice from this blogger. Much more important is his admonitions to focus on features and not phases, to build the best features first, to deliver every two months, and to collaborate with your business partner. I gave some very similar advice recently in one of my own posts.
Thursday, January 24, 2008
Agile For Dummies
I just ran across this blog post on Agile Software Development called Don't Know What I Want But I Know How to Get It. One of Agile's main tenets is that software development should be iterative and incremental. The author of this article does a great job of educating just precisely what those two words mean.
This is a great introduction to Agile methodology. The author does a good job at bridging the gap between customer expectations and software engineering reality in a light hearted and humorous way.
This is a great introduction to Agile methodology. The author does a good job at bridging the gap between customer expectations and software engineering reality in a light hearted and humorous way.
Saturday, January 12, 2008
What Should Students of Software Engineering Learn?
A recent defense department article lamented the decline in quality of computer science graduates. They laid the blame on today's institutions of higher education. The big troll in the article that has generated the most buzz is the claim that students who first learn Java are somehow mentally hamstrung to those who first learn C++. This was based on some private communication with Bjarne Stroustrup who is the inventor of C++.
The reason why the group of students, who first learned C++, outperformed the group of students, who first learned Java, is because C++ is harder to learn than Java. The C++ group is smarter because the ones who couldn't learn C++ dropped out. This skewed the average intelligence of the C++ group higher than that of the Java group.
I do agree with the article that, in order to be a good programmer, you should learn multiple programming languages. I learned a lot from studying the following languages; assembler, C++, C#, Java, Lisp, Python, and Ruby.
The other point about the article that I agree with is the need to teach more than programming languages. In fact, I would go one step further. Teach the computer science concepts in class and the programming languages only in the labs. It's the concepts that hold the most value and should be the center of attention.
The reason why the group of students, who first learned C++, outperformed the group of students, who first learned Java, is because C++ is harder to learn than Java. The C++ group is smarter because the ones who couldn't learn C++ dropped out. This skewed the average intelligence of the C++ group higher than that of the Java group.
I do agree with the article that, in order to be a good programmer, you should learn multiple programming languages. I learned a lot from studying the following languages; assembler, C++, C#, Java, Lisp, Python, and Ruby.
The other point about the article that I agree with is the need to teach more than programming languages. In fact, I would go one step further. Teach the computer science concepts in class and the programming languages only in the labs. It's the concepts that hold the most value and should be the center of attention.
Friday, August 10, 2007
Putting the Money Where the Mouth Is
About a year ago, I was talking with the founders of an under-the-radar startup whose name and identifying details need not be mentioned here. At that time the technical founder was quite jazzed on a web application platform and development language called Ruby on Rails. I checked back in with them recently to discover that they had changed their tune and were now looking for both Ruby and Java developers. As business application software development is my field, I was quite curious to discover what had happened in that year's time. The technical founder explained that they needed Java for some interoperability reasons that he did not go into detail about. The most significant reason, however, was that they were having a lot of trouble finding Ruby developers for hire.
I should mention that they are located in the Bay Area of California which is, IMHO, ground zero for cutting edge, innovative, software development. I was shocked to hear that they were having trouble finding Ruby developers there since I hear a lot of enthusiasm for Ruby, especially coming from the Bay Area. What happened?
The other day, I was having lunch with a peer who works as a software architect in a different ISV (not a competitor). He is a very vocal and strong proponent for Ruby. I told him the story and asked him if he would take a Ruby job. He thought about it for a moment and then declined. It turns out that when career, professional software developers choose to learn about and endorse a new development platform, they make that choice based on technical merit. When those same developers make a career choice, however, technology doesn't figure very prominently in the decision making process.
There is some irony here as a common complaint amongst software developers is that management doesn't make good decisions because they don't sufficiently evaluate the technical merit or impact of their decisions.
I find it strangely curious that career professionals would spend time learning and endorse a technology that they had no intention of pursuing professionally. It takes both time and mind, limited resources, to learn a new application stack. When a software developer choses to learn a new application stack, then he or she is making an investment. Doesn't it make sense to expect a return on your investment? Of course, learning itself, is also a valuable thing; therefore you do get some return on your investment. Wouldn't it be better if you maximized your return on investment by learning technology that was cool and marketable?
I, personally, am not saying that Ruby is unmarketable. I, personally, don't need a deep pockets, high profile software infrastructure company to spend bazillions of marketing dollars before I judge a technology as marketable (although it doesn't hurt). What I am saying is that, apparently, there is a non-trivial number of developers who endorse technology that they believe to lack sufficient market share for them to add it to their resume.
Why would that be risky? The more irrelevant technology is on your resume, the less marketable you are. Time and mind aren't the only limited resources for a professional software developer. Resume column inches is another.
Maybe they endorse Ruby hoping that enough people will endorse it so that it becomes marketable but that the watershed moment just hasn't happened yet. Maybe that early enthusiasm was based more on potential and promise than on actual delivery. There has been some performance issues with RoR, enough to prompt MSFT to weigh in with their own version.
A marketplace is a place where buyers and sellers come together to exchange different forms of capital. If something isn't perceived as worthy of buying or selling, then it doesn't have a place in the marketplace. The more perceived worth by buyers and sellers, the more buyers and sellers who perceive worth, the bigger the place it takes up in the marketplace.
Software developers, if you like Ruby enough for it to be marketable, then you are going to have to be willing to do Ruby work for pay and to put it on your resume. You may have to take on the extra risk of being an early adopter because followers aren't going to anywhere without leaders.
I'd like to get more feedback from other developers. What's your take on this? Is Ruby marketable today? Would you take a Ruby job now? Why or why not?
I should mention that they are located in the Bay Area of California which is, IMHO, ground zero for cutting edge, innovative, software development. I was shocked to hear that they were having trouble finding Ruby developers there since I hear a lot of enthusiasm for Ruby, especially coming from the Bay Area. What happened?
The other day, I was having lunch with a peer who works as a software architect in a different ISV (not a competitor). He is a very vocal and strong proponent for Ruby. I told him the story and asked him if he would take a Ruby job. He thought about it for a moment and then declined. It turns out that when career, professional software developers choose to learn about and endorse a new development platform, they make that choice based on technical merit. When those same developers make a career choice, however, technology doesn't figure very prominently in the decision making process.
There is some irony here as a common complaint amongst software developers is that management doesn't make good decisions because they don't sufficiently evaluate the technical merit or impact of their decisions.
I find it strangely curious that career professionals would spend time learning and endorse a technology that they had no intention of pursuing professionally. It takes both time and mind, limited resources, to learn a new application stack. When a software developer choses to learn a new application stack, then he or she is making an investment. Doesn't it make sense to expect a return on your investment? Of course, learning itself, is also a valuable thing; therefore you do get some return on your investment. Wouldn't it be better if you maximized your return on investment by learning technology that was cool and marketable?
I, personally, am not saying that Ruby is unmarketable. I, personally, don't need a deep pockets, high profile software infrastructure company to spend bazillions of marketing dollars before I judge a technology as marketable (although it doesn't hurt). What I am saying is that, apparently, there is a non-trivial number of developers who endorse technology that they believe to lack sufficient market share for them to add it to their resume.
Why would that be risky? The more irrelevant technology is on your resume, the less marketable you are. Time and mind aren't the only limited resources for a professional software developer. Resume column inches is another.
Maybe they endorse Ruby hoping that enough people will endorse it so that it becomes marketable but that the watershed moment just hasn't happened yet. Maybe that early enthusiasm was based more on potential and promise than on actual delivery. There has been some performance issues with RoR, enough to prompt MSFT to weigh in with their own version.
A marketplace is a place where buyers and sellers come together to exchange different forms of capital. If something isn't perceived as worthy of buying or selling, then it doesn't have a place in the marketplace. The more perceived worth by buyers and sellers, the more buyers and sellers who perceive worth, the bigger the place it takes up in the marketplace.
Software developers, if you like Ruby enough for it to be marketable, then you are going to have to be willing to do Ruby work for pay and to put it on your resume. You may have to take on the extra risk of being an early adopter because followers aren't going to anywhere without leaders.
I'd like to get more feedback from other developers. What's your take on this? Is Ruby marketable today? Would you take a Ruby job now? Why or why not?
Monday, August 6, 2007
Renaissance Software Development
I recently read a blog post called A Guide to Hiring Programmers: The High Cost of Low Quality in which Frank Wiles makes the case, when staffing a software development project, to hire good coders even if it means sacrificing everything else. Serendipitously enough, I also read a book called The Business of Software by Erik Sink in which the choice, at least for small ISVs, is to hire developers instead of programmers. Developers code but they also can do other things such as design, model, and interview customers in order to capture specifications or defects. I am interested in these different styles or philosophies in software development because of my long history of experience in the field.
Frank advises not to even bother with the requirement that they are familiar with the target programming language or application platform stack. He also advises to let them telecommute 100% of the time if they want to. His reason for all of this is the claim that a good quality programmer will be 10 times more productive than an average coder. My guess is that the big boost in productivity will come once they learn the environment, etc.
Erik makes the case that a good, well-rounded developer will advance the project faster than a hot code specialist. If you had to choose between an average developer and an excellent programmer, then you should pick the developer.
It's really the choice between generalists and specialists which, really, is no choice at all. A project full of specialists may produce something brilliant but it is unlikely to advance the stated goals of the organization. A project filled with generalists might produce something completely on target but with a very lackluster execution. I say, let's embrace the genius of the and over the tyranny of the or and staff the project with both. Use the generalists to keep the project nimble and on target. Use the specialists to quickly solve any advanced technical problems that will arise. You wouldn't play chess with all bishops or send out nothing but running backs on to the football field. Why would you do the same thing in software development?
Frank advises not to even bother with the requirement that they are familiar with the target programming language or application platform stack. He also advises to let them telecommute 100% of the time if they want to. His reason for all of this is the claim that a good quality programmer will be 10 times more productive than an average coder. My guess is that the big boost in productivity will come once they learn the environment, etc.
Erik makes the case that a good, well-rounded developer will advance the project faster than a hot code specialist. If you had to choose between an average developer and an excellent programmer, then you should pick the developer.
It's really the choice between generalists and specialists which, really, is no choice at all. A project full of specialists may produce something brilliant but it is unlikely to advance the stated goals of the organization. A project filled with generalists might produce something completely on target but with a very lackluster execution. I say, let's embrace the genius of the and over the tyranny of the or and staff the project with both. Use the generalists to keep the project nimble and on target. Use the specialists to quickly solve any advanced technical problems that will arise. You wouldn't play chess with all bishops or send out nothing but running backs on to the football field. Why would you do the same thing in software development?
Subscribe to:
Posts (Atom)
