testers get no respect. Ten years from now: The most important members of the team will be its agile coaches and champions; testers still will get no respect.
Ten years ago: Software development was seen as a wonderful career, even after the dot-com implosion. Today: Software development is a wonderful career, but the recession has affected many enterprise jobs. Ten years from now: New tools will empower less-technical professionals to build applications, but software development will still be a wonderful career, as we take on the hard problems that nobody else can solve.
Ten years ago: SD Times launched. Today: On July 15, 2010, we celebrate the publication of our 250th issue. Ten years from now: The future’s so bright, we’ll have to wear shades.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 10:07 AM 0 comments
The danger of monocultures
Ten years ago: The Web was everything, and browsers were how desktops and mobile devices (in their limited way) dealt with Internet-based services. Today: Desktops are browser devices but mobile devices increasingly use apps to manipulate Internet services as diverse as Facebook, reading newspapers and enterprise resources. Ten years from now: Apps will have taken over mobile devices entirely, and “walled garden” apps will be a significant presence on the enterprise desktop. The browser will be far less important than it is today.
Ten years ago: Distributed development teams just starting to leverage Internet bandwidth, hosted SCM systems and collaboration systems – but even so, most developers lived in their IDEs. Today: The value of collaboration tools has been proven, and in many organizations, sophisticated ALM suites have turned the stand-alone developer into an endangered species. Ten years from now: More and more ALM functionality will migrate onto servers, particularly hosted servers across the Internet. IDEs will be turning into front-end apps. Source code and metadata will live in cyberspace.
Ten years ago: Most serious enterprise developers worked with native compiled languages, with the primary exceptions of Web script, Visual Basic and Java. Today: Managed languages like Java, C#, Perl, PHP and Python rule the enterprise, with C/C++ and other native languages being seen as specialist tools for those who need to stay close to the hardware. Ten years from now: With the exception of device developers, the world will belong to managed runtimes and virtual machines.
Ten years ago: Databases meant a SQL-based relational database from a company like Oracle or IBM. Today: While most enterprise data is still in a large SQL-based RDMS, such as OracleDB, DB2 or SQL Server, many development teams have embraced lighter-weight alternatives like MySQL and are playing with NoSQL alternatives. Ten years from now: Most enterprise data will still be in giant relational databases, but there will be more acceptance of those alternatives.
Ten years ago: The most important members of a software development team were its programmers; testers got no respect.e media. And other stuff.
7.22.2010
Mainframe are not legacy systems!
I’m a mainframe guy. Cut my teeth writing COBOL, PL/I and FORTRAN on the IBM System/370. CICS is my friend. Was playing with virtual machines long, long before there was anything called “DOS” or Windows” or Linux.” My office closet is filled with punch cards and old nine-track tapes, all probably unreadable today. One of the happiest days of my professional life was trading in an old TeleVideo 925 monochrome terminal for a brand-new 3279 color display.
If you listen to just about any marketer in the software development or IT industry, mainframes are always described as legacy systems – with the implication that only a total loser would continue to use such an outdated piece of junk.
By casually repeating terms like “legacy system,” or buying into the phrase “legacy modernization” for projects that integrate mainframes with other platforms like Java and .NET, everyone perpetuates the marketing myth that mainframes are bad. That they’re relics whose time has come and gone. That the goal of any IT professional should be to replace every mainframe with something else – anything else.
I say, “Bah, humbug. Nonsense. Fiddlesticks. Balderdash.”
The Wikipedia defines a legacy system as
A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users’ needs, even though newer technology or more efficient methods of performing a task are now available. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used.
In many situations, there is no more efficient tool for solving a business problem than a mainframe. Mainframes are just as current, just as new, just as relevant and just as useful as any other modern, state-of-the-art IT platform. Mainframes are not legacy systems.
Now, are some mainframe applications legacies? Yes. Any application that hasn’t been properly maintained becomes obsolescent. If you’re having to do extensive wrappering around an old COBOL or RPG program that nobody understands in order to keep it running, then you’ve got a problem. But the problem isn’t that it’s running on a mainframe. The problem is that the software wasn’t properly documented and that your engineers weren’t properly trained.
A 30-year-old undocumented C# program running on .NET, or a 30-year-old undocumented C++ program running on Solaris or a 30-year-old undocumented Java program running on WebLogic will be just as “legacy” as a 30-year-old CICS program running on z/OS.
Today, IBM released a new family of mainframes, called the zEnterprise 196. I don’t know much about it – I haven’t touched a mainframe since the early 1980s. But I do know one thing: It’s not a legacy system.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 5:39 PM 1 comments
7.15.2010
Celebrate 250 issues of SD Times by looking forward to the year 2020
What will software development be like in the year 2020? It would be easy to draw a straight line from ten years ago through today, and see where it goes a decade from now.
Ten years ago: Hosted applications through ASPs (application service providers) were getting started, but had little impact. Today: Hosted applications through the cloud and SaaS providers are having some impact on enterprise data centers, particularly in smaller companies. Ten years from now: Hosted applications will be mainstream, and IT managers will have to justify running applications on-premise.
Ten years ago: The Web was everything, and browsers were how desktops and mobile devices (in their limited way) dealt with Internet-based services. Today: Desktops are browser devices but mobile devices increasingly use apps to manipulate Internet services as diverse as Facebook, reading newspapers and enterprise resources. Ten years from now: Apps will have taken over mobile devices entirely, and “walled garden” apps will be a significant presence on the enterprise desktop. The browser will be far less important than it is today.
Ten years ago: Distributed development teams just starting to leverage Internet bandwidth, hosted SCM systems and collaboration systems – but even so, most developers lived in their IDEs. Today: The value of collaboration tools has been proven, and in many organizations, sophisticated ALM suites have turned the stand-alone developer into an endangered species. Ten years from now: More and more ALM functionality will migrate onto servers, particularly hosted servers across the Internet. IDEs will be turning into front-end apps. Source code and metadata will live in cyberspace.
Ten years ago: Most serious enterprise developers worked with native compiled languages, with the primary exceptions of Web script, Visual Basic and Java. Today: Managed languages like Java, C#, Perl, PHP and Python rule the enterprise, with C/C++ and other native languages being seen as specialist tools for those who need to stay close to the hardware. Ten years from now: With the exception of device developers, the world will belong to managed runtimes and virtual machines.
Ten years ago: Databases meant a SQL-based relational database from a company like Oracle or IBM. Today: While most enterprise data is still in a large SQL-based RDMS, such as OracleDB, DB2 or SQL Server, many development teams have embraced lighter-weight alternatives like MySQL and are playing with NoSQL alternatives. Ten years from now: Most enterprise data will still be in giant relational databases, but there will be more acceptance of those alternatives.
Ten years ago: The most important members of a software development team were its programmers; testers got no respect. Today: The most important members of a team are seen as its architects; testers get no respect. Ten years from now: The most important members of the team will be its agile coaches and champions; testers still will get no respect.
Ten years ago: Software development was seen as a wonderful career, even after the dot-com implosion. Today: Software development is a wonderful career, but the recession has affected many enterprise jobs. Ten years from now: New tools will empower less-technical professionals to build applications, but software development will still be a wonderful career, as we take on the hard problems that nobody else can solve.
Ten years ago: SD Times launched. Today: On July 15, 2010, we celebrate the publication of our 250th issue. Ten years from now: The future’s so bright, we’ll have to wear shades.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 10:07 AM 0 comments
The danger of monocultures
When you think about a modern software monoculture, which company do you think of first? Chances are that it’s Apple. However, if I asked that question between, say, 1995 and 2007, you probably would have said Microsoft.
In agriculture, a monoculture is when too much of a region plants exactly the same crops. If there’s a disease or pest that destroys that crop, the entire region is in big trouble. Similarly, if the economics of that crop change – like a price collapse – everyone is in trouble too. That’s why diversity is often healthier and more sustainable at the macroeconomic level.
However, the problem with a monoculture is that it’s an attractive nuisance. If all your neighbors are planting a certain crop and are making a fortune, you probably want to do that too. In other words, while monocultures are bad for society as a whole, they’re often better for individuals – at least until something goes wrong.
Microsoft’s dominance over the past couple of decades turned into a monoculture. Vast numbers of consumers and enterprises standardized on Windows and Office, because that’s what they knew, that’s what was in stores, that’s where the applications were and because for them personally, it seemed to be the right choice. to go with the flow.
While there were alternatives, like Unix and Linux and the Macintosh, those remained niche products (especially on corporate desktops), because a monoculture rewards going with the flow and jumping on the bandwagon. Monocultures foster a lack of competition and a desire to play it safe. Nobody wants to upset the bandwagon. And thus, real innovation at Microsoft didn’t make it into Windows and Office – leaving room for the Macintosh to take risks, build a compelling product and start taking market share, and for Linux to tackle and win the early netbook market.
Today, Microsoft’s Windows and Office still dominate the enterprise. But even with Windows 7, I don’t think that customers are quite as willing to just to whatever Microsoft says as they used to be.
In the smartphone wars, the iPhone never became a real monoculture – there are too many BlackBerrys and other devices. However, certainly the media acts as if the iPhone is the only game in town. Apple plays into the perceptions of monoculture, offering essentially one model handset (now the iPhone 4), with the only variations being a choice of two colors and three memory configurations.
Apple’s dismissal of the well-publicized flaws in the iPhone 4’s antenna – first saying that it was a user error (you’re holding the phone wrong), and then claiming it’s a trivial software bug (displaying an incorrect signal strength) – shows incredible arrogance. And I say that as a happy iPhone 3GS owner and long-time Mac user who frequently recommends Apple products to friends and colleagues.
Any company can release a product that has a flaw. However, Apple’s behavior has been astonishingly bad. And if Apple wasn’t trying to impose a software monoculture by offering essentially one handset, it wouldn’t be a big deal. If Apple offered half-a-dozen iOS handsets, if one had a bad antenna, nobody would even notice.
The upshot, of course, is that while Apple is sure to fix the problem, we may see the early demise of the perceived iPhone monoculture. Android is coming on strong with a fast-evolving operating system and a lot of innovative work from handset makers and app developers. While I have no plans to migrate from my iPhone 3GS right now, I would definitely consider an Android device for my next purchase. Monocultures are bad, and we all benefit from a rich and diverse marketplace.
Save to del.icio.us • Digg This! (1 Digg) • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 9:58 AM 0 comments
7.07.2010
Cloud this, cloud that
Is literally everything about the cloud? You’d think so, going by the chatter from the biggest industry players. It seems that every company that wants to talk to be is pushing something to do with cloud computing. New service offerings from hosting providers. New tools for optimizing the performance of applications, or for making it easier to migrate, or for making cloud-based development more agile.
The cloud sure is seductive. In our company, we’re considering a migration to cloud technologies within the next 12 months. BZ Media, the organization behind SD Times, is a small company, and frankly I’d rather not be maintaining server, either in-house or dedicated hardware in a collocation center. If the economics of cloud computer work out, and if reliability and scalability deliver what we need, then it’s a good thing.
Yet I’m puzzled. How much is cloud computing a software development conversation, rather than an operations conversation? Obviously the platforms are different: Windows Azure is different than Windows Server 2008. Microsoft’s SQL Azure is different than Microsoft’s SQL Server. The Java EE that VMware is pushing into Saleforce.com’s cloud isn’t the same Java EE that’s on your current in-house app server. Working with Amazon S3 is not the same as working with an EMC storage array. So yes, there’s an undeniable learning curve ahead. But that’s what you’d encounter in any significant server platform change, whether cloud, on-premise or collocated.
Therefore, my confusion. How much does a software development team need to know about the cloud, beyond how to deploy to it and integrate applications with cloud-based apps? Often, I believe, not much.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 10:49 AM 1 comments
6.17.2010
Securing the applications
IBM Rational has written a solid white paper on software security, focusing on improving code reviews. Although I rarely (very rarely) endorse a vendor white paper, this is one that’s worth reading.
Written in December 2009 by Ryan Berg, a senior security architect at IBM, the paper focuses on best practices for examining code for security flaws, and then figuring out how to remediate those flaws. The paper, called “The Path to a Secure Application,” breaks the vulnerabilities into five specific categories, each of which is examined in detail:
• Security-related functions
• Input/Output validation and encoding errors
• Error handling and logging vulnerabilities
• Insecure components
• Coding errors
For each of those vulnerability categories, Berg describes specific instances and offers a list of suspicious code behavior that might indicate problems. For example, for insecure components, he offers that you might have unsafe Java Native Interface methods, or unsupported methods. Suspicious behavior would include raw socket accesses, which could indicate possible backdoors; timer or get-time functions, which might mean triggers; or privilege changes, which might speak to unauthorized access levels within the code.
What’s nice about this paper is that – unlike many that cross my desk – Berg isn’t setting up a paper tiger. He’s not highlighting flaws so that he can say, “Oh, look, IBM sells tools to solve this problem, call us today.” While IBM Rational does offer source-code scanning tools, this white paper ain’t peddling them. Rather, Berg is offering guidelines for making a QA checklist for reviewing source code for secure vulnerabilities. Nicely done! I wish more white papers were this good, and this genuinely educational.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 3:24 PM 0 comments
6.11.2010
The modern programmable portable sensor pack
Battery-powered. Built-in satellite-based Global Positioning System receiver. Accelerometer. Ambient light sensor. High-resolution camera. Powerful processor. Gigabytes of storage. Radios for communicating with Bluetooth devices, WiFi networks and cellular data systems. And now, even an embedded gyroscope.
The sensor and communications capabilities of today’s smartphones is astonishing. Each generation of device, whether from Apple or its competitors, crams more and more sophisticated electronics into a pocket-sized package, with the latest being the iPhone 4’s gyro.
All you need is a life-forms sensor and a probe for detecting buried dilithium deposits, and today’s smartphones would be right at home on the U.S.S. Enterprise. Oh, a tachyon emitter would be nice too.
We’ve been here before, of course. In early 2007, Sun Microsystems gave me a Sun SPOT development kit. A SPOT – Small Programmable Object Technology – was a battery-powered device equipped with a small ARM processor, short-distance radio, accelerometer, temperature and light sensors, some multi-colored LEDs and general-purpose analog and digital I/O ports, managed by an embedded Java virtual machine. I did some experiments with the SPOT and was impressed with its capabilities. Sadly, the Sun SPOT initiative faded out after its first limited production run.
General-purpose smartphones, whether based on Apple’s iOS (the new name for iPhone OS), Google’s Android or Microsoft’s Windows Phone 7, have the potential to revolutionize remote sensing. Not only is the array of built-in sensory apparatus impressive, but the ability to add more through hard-wired or Bluetooth connections takes that a set farther. I don’t know if there are third-party toolkits yet for adding analog and digital inputs to smartphones – but there should be.
Already there are kits for connecting smartphones to a car’s OBD-II to pull down a vast array of real-time onboard diagnostics. Software uses that data, plus the phone’s accelerometer, to measure acceleration and performance.
Look at a smartphone, and forget, for a moment, that it’s a phone. Think about its sophisticated electronics, processing power, radio capabilities, and sensory functionality. Imagine how it could be used for science and engineering — both in the lab and in the real world. Think about the low price, well under $1,000 (forgetting about carrier subsidies). Amazing, isn’t it?
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 4:48 AM 0 comments
6.03.2010
Is Continuous Deployment the next step forward in agile development?
Speed matters. With most agile development methodologies, the faster you can push new code out into the source-code management system, into builds and onto servers, the faster you can evaluate your progress and chart your next moves. From monthly builds came weekly builds, then daily (or nightly) builds. In some shops, those builds are used internally, with less-frequent deployments into the production environment. In other cases, the bits are actually pushed out to production servers daily.
Even the now-common daily/nightly build and deployment may not be fast enough to drive modern development, according to some proponents of ever-more-agile agile methodologies. That’s why thinkers like Kent Beck (pictured) are now advocating a move from Daily Deployment to Continuous Deployment.
Continuous Deployment is the topic of the first-ever SD Times Virtual Conference, which we’re holding on Wednesday, June 30, beginning at 1:00pm Eastern (10:00am Pacific). There’s no cost to attend this three-hour educational event, which I’ll be hosting.
Our three instructors are Kent Beck, founder and director of the Three Rivers Institute, and author of “Implementation Patterns,” “Extreme Programming Explained: Embrace Change,” and much more; Timothy Fitz, tech lead at IMVU and one of the creators of the Continuous Deployment movement; and Jez Humble, build-and-release manager at ThoughtWorks Studios, who is currently writing a book called, appropriately enough, “Continuous Deployment.”
Here’s what we’re going to cover in the virtual conference – you can stay for the whole thing, or choose the parts that seem more relevant to you:
• The potential benefits of Continuous Deployment to your organizations.
• The technology required to implement Continuous Deployment.
• How to apply Continuous Deployment to your company’s existing IT systems.
• How to apply Continuous Deployment to the software you’re creating, both Web and client-installed.
• The social challenges of applying Continuous Deployment in your organization.
• The risks of doing Continuous Deployment wrong – and how you can avoid mistakes.
• The impact of Continuous Deployment on various job functions: testers, marketers, managers, programmers and other stakeholders.
• The prerequisites to Continuous Deployment.
• Practical advice and best practices to take steps toward Continuous Deployment today.
You can learn more, see the agenda and timeline, and pre-register at http://bzmedia.com/agility/ — please join us!
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 1:31 PM 0 comments
6.01.2010
Making sense of Salesforce.com
Salesforce.com intrigues me, and that’s a positive thing. The company keeps reinventing itself, and shows the type of innovation that used to be more common in Silicon Valley.
If you thought that Salesforce was in the business of hosting customer relationship management software, you’re living in the past. CRM barely scratches the surface of where the company is today. Sure, the company describes itself as “Web-based Customer Relationship Management (CRM) Software-as-a-Service (SaaS),” but when was the last time you heard anyone talking about the company’s CRM systems?
With Salesforce today, it’s all cloud, cloud, cloud. And chocolate – Salesforce is very popular with my family, since the company’s public-relations team bundles bags of chocolate with its press-release packets. Full disclosure: It’s delicious. Also, our advertising sales team uses Salesforce’s CRM system.
Chocolate? By sending out press packets with tasty treats, Salesforce keeps demonstrating that it’s an old-fashioned company innovating with the latest technologies. Very few companies mail out printed materials to journalists any more. Everything is all email and Web pages, webcasts and blogs. Yet there’s something appealingly archaic – positively 1980s – about this corporation.
Salesforce was born in 1999, launched by former Oracle sales executive Marc Benioff. Some analysts (myself included) formed an initial impression that Benioff – a brash showman not unlike Larry Ellison –formed the startup to tactically exploit the hosted CRM market focusing on small and mid-sized customers. A decade ago, that was a niche opportunity that Oracle was far too big to serve.
Benioff would gain some traction in the CRM space, we predicted, and then sell Salesforce.com within a few years. Probably back to Oracle, but if not, to SAP, IBM or another IT-industry giant. If Oracle was the buyer, Benioff would be well positioned as Ellison’s eventual successor at Oracle’s helm.
Yes, I still predict that Oracle or another large firm will acquire Salesforce. My estimate is that it’ll happen within five years. But while the company’s CRM assets are essential because subscriber fees drive substantial revenue, the real intellectual property will be in Salesforce’s cloud technology.
The revenue is growing nicely. According to Salesforce’s fiscal first-quarter results, covering January-March 2010, the quarter’s revenue was US$376.8 million, an increase of 24% over the same period in 2009. Subscription and support revenues made up nearly all of that, coming to $351 million; the rest was professional service. While that’s paltry compared to Oracle’s first-quarter 2010 revenues of $5.1 billion, it’s nothing to sneeze.
There’s no sneezing at Salesforce’s market cap either, which was $10.74 billion in late May, with a price/earnings ratio of 134.17. By comparison, Oracle’s market cap is $112.12 billion, with a P/E of 19.96.
What’s driving the market cap? The cloud. Of course, as a hosted CRM service, Salesforce has always lived in the cloud, even before term gained widespread currency. What distinguished Salesforce years ago from other hosted software companies – and linked it to much-larger cloud pioneers like Amazon and Google – is that the company realized that its hosting infrastructure and database engine could be leveraged by its customers for running custom software. Initially, most custom software was coupled tightly to the CRM service, but increasingly, the capability has taken on a life of its own and has attracted customers beyond Salesforce’s traditional installed base.
So, while cloud service fees are only a small part of Salesforce’s current revenue stream today, it represents the leading edge of the company’s innovation and attraction. To be blunt, that’s the only reason why we cover Salesforce in SD Times – because hosted CRM isn’t an area of interest to the typical enterprise developer or ISV software engineer.
Look at what Salesforce has done with the cloud. It’s gone beyond its simple Apex and VisualForce programming languages – designed to create add-ins to the CRM system – to a richer environment, called Force.com, that’s trying to appeal to all enterprise developers. The company moved into collaboration with its new Chatter system. It created an application store, AppExchange, to let developers choose from pre-written tools and services. It supports rich Internet apps using Flash, CSS and JavaScript. Most recently, the company has partnered with VMware to host a subset of Java EE within the cloud.
Balance sheet notwithstanding. Salesforce.com is no longer about CRM. To my earlier prediction that the company will be acquired with five years, let me add two more. First, its name no longer fits. I see a name-change within the next two years. And that stock ticket, NYSE:CRM – that’s gotta go. It looks like NYSE:CLWD is available.
Save to del.icio.us • Digg This! • Technorati Links • Email this • Slashdot Bookmark This • Submit to Reddit
Posted by Alan Zeichick at 1:27 PM 0 comments
5.31.2010
Get ready for the SD Times 100
It’s almost time to unveil the SD Times 100 – the top 100 companies, project and movements that are demonstrating innovation and leadership in the software development industry.
This year, the SD Times 100 will be “officially” published in the June 1, 2010, issue of SD Times. It’ll also appear on that date on sdtimes.com.
However, continuing a new tradition begun last year, we will tweet out the SD Times 100, category by category, on Monday, May 31, starting around 11:00am Eastern, 8:00am Pacific. We’ll begin with the “Agile & Collaboration” category, and will tweet another category every 30 minutes or so, continuing through all 12 categories until we reach the biggest one: Influencers.
See all the action by following us on Twitter: www.twitter.com/sdtimes.
