Phurnace Blog

Beginning in the 90’s, American software companies began farming out development work to companies overseas, or "off-shoring". These efforts mirrored what had been taking place for quite some time in other industries, such as textile manufacturing, and sent tremors through the software community. The heady days of the dot-com boom gave way to fear and gnashing of teeth in the early part of this decade. CEO’s were pictured riding astride elephants in India, and executives were predicting that soon all non-design development work would take place off-shore. Would there be any jobs left for American software developers?

Now entering the latter part of this first decade of the 21st century, the software development community state-side finds itself in what appears to be a better situation, jobs-wise. What happened? Why did the gloom-and-doom scenarios not play out?

A couple of realities have become apparent as the decade has played itself out. First, globalization of software development has actually worked against itself, as the cost of doing business in countries like India has increased to the point where the cost savings benefit is in question. Software developers are able to demand more money there, as the need for them has increased.

But secondly, and I believe just as importantly, companies seeking to off-shore their development made critical mistakes in choosing the products that they would send overseas. The products they chose were mostly mainstream, legacy products, which tend to be, by their sheer longevity, much more complex and intricate. From my experience in this business, I have found that "old" does not equal "simple". In fact, just the opposite is true. This software has generally been developed over the years by hundreds of developers, all with different programming styles, and do not always follow textbook patterns. Asking primarily inexperienced developers to maintain or enhance these products without day-to-day guidance from at least a few senior developers is tough. Couple this fact with the risk of losing market share for these products (oh yeah, they’re probably still profitable, why else would development continue?), and you have a recipe for disaster.

What seems like such a great idea when discussed at cocktail parties 8 years ago, should now be one that should be considered with at least some trepidation.

In Untagged 
Comment (0) Read More...

A long time ago, I was on a NOLS adventure in the middle of the Olympic mountains. My group was resting one day high above the tree-line in a snow covered area when we found a small, but steep bank of snow ... perfect for headfirst nosedives. It all seemed harmless at the time, until our guide angrily reminded us that whatever choices we make, the fact remains, we must weigh the risk versus the reward. Shocked at first by his reaction, we all suddenly had the realization that given our surroundings and circumstances, the risk we were taking was much greater than the reward.

This article about Twitter recently reiterated to me some real risks with Ruby on Rails. Whether or not Twitter is abandoning Ruby on Rails, the risk of a severely flawed framework remains.

Ruby on Rails is a language and platform that makes web application development quicker and more maintainable. One of its strength is that the Rails Framework enforces consistency in style and encourages code reuse. Past that, Ruby as a language is just another language. Rails is an innovative framework, but it is only a framework. Many arguments are made regarding the technicalities of Ruby and other languages.

I do not wish to rehash these arguments; but instead, I make an assertion that by choosing the Ruby on Rails platform in an "Enterprise" environment, your organization is taking unnecessary risks considering its surroundings.

For the last two years or so I noticed a new wave of energy surrounding Ruby on Rails. I encountered some very strong proponents of Ruby on Rails who wanted to use it in an Enterprise setting -- I always had one simple concern:

Ruby on Rails is a two tiered platform; thus, fundamentally flawed. A Ruby on Rails application is doomed to scalability issues. So while it may be fun implementing a web application using a new innovative platform, it will not be fun when your company is finally on the verge of success only to discover it has a severely under-performing application on a platform that provides few options to scale. Twitter anyone?

Now, consider the recent support that companies such as IBM have put behind a long time leading web application language, PHP. By leveraging PHP, a developer can now overcome many of the "ease-of-development" drawbacks of developing a traditional multi-tiered Java based web application, but still have the facilities of a highly scalable application server environment such as WebSphere XD.

Much like sledding down a hill, creating a simple web application using Ruby on Rails has its advantages. However, when you consider the surroundings of an Enterprise Environment, it is hard to consider any situation that Rails is worth the risk.

In Twitter, Ruby on Rails, PHP
Comment (4) Read More...

As a software developer, maintaining concentration is something that requires discipline, and sometimes the aid of a good set of headphones, and some music.  While this usually does the trick, I find that familiar music can be its own distraction, since I find myself jumping to some memory that the song brings back.  In addition to this, transporting CDs back and forth from home to work is a pain.

For these, and other reasons, I've looked for alternative listening sources, and one I've found very enjoyable are the Internet radio channels streamed at Soma FM.  This full-time, Internet-only station began as a pirate radio broadcast at the Burning Man festival in 1999, and now streams 16 different channels.  My personal favorites are Groove Salad, which plays music in the Ambient genre, and indie pop rocks!, playing new and old tunes.  In listening to these two channels, I've discovered a lot of new music (which is harder to do the older I get), but at the same time, I find that I'm able to keep my focus on my development work, since I'm not as familiar with the bands.

If you're looking for some really great music to work by, check them out.  I think you'll find some great music which just requires an Internet connection to enjoy.

In Untagged 
Comment (0) Read More...

We are pleased to announce that Phurnace's flagship product, Phurnace Deliver™ is now directly integrated with IBM® Rational® Build Forge®. We invite you to hear all about it in our upcoming webinar - Accelerating the Software Development to Deployment Lifecycle Are you ready for one process to compile, build, deploy and configure your applications?

In this webinar, we will show you how to do that with IBM® Rational® Build Forge® and Phurnace Deliver™ products. We will explore how to use Build Forge and Deliver together to have a uniform, fully automated build and deployment process without the use of scripts or manual intervention. We will discuss how to use the combined products to check-out, build, deploy, and configure your JavaEE applications automatically. In addition, we will discuss how to preview configuration changes, keep logs of configuration and code deltas, compare configurations across servers, as well as how to manage the sometimes chaotic process of building and deploying complex enterprise applications.

Date: Friday, May 9, 2008
Time: 2:00PM - 3:00PM CST
Location: Online
Presenters: Leigh Williamson, Distinguished Engineer, Rational Software Architecture and Development, IBM & Daniel Nelson, Vice President of Products, Phurnace Software
Registration: Please register here to reserve your space.

We hope to see you there!

In Deployment, Configuration, Build Forge
Comment (0) Read More...

There are quite a few toolkits available for Java developers. Let me help point you in some directions and maybe save you some research time.

Many of you will be familiar with the Abstract Windows Toolkit (AWT) that is available with every Java Runtime Environment (JRE). AWT is the original Java GUI toolkit developed by Sun Microsystems. AWT is a peer-based toolkit meaning that each AWT control is dependent upon a host operating system control. AWT usage is limited because it was designed to only support controls which are available in all Java host environments. For example, AWT does not support Trees and Tables.

Swing is another Java GUI toolkit developed by Sun Microsystems and was designed to work with AWT and is built on top of AWT components. Unlike AWT, most Swing controls are emulated. This emulation makes user interfaces written in Swing portable across all operating systems and supports Sun’s “write-once, run anywhere” motto. One disadvantage to Swing is that the emulated controls often don’t result in a native looking application. Swing’s answer to this problem is provided by look-and-feel emulators that attempt to change the appearance and behavior of their components to adapt to a particular operation system or theme. Another disadvantage to Swing is that the emulated controls tend to run slower than peer-based controls.

The Standard Widget Toolkit (SWT) is another peer-based GUI toolkit. IBM designed SWT to solve some of the problems that have limited the usage of AWT. SWT provides a different Java implementation for each operating system platform using Java Native Interface (JNI) calls. One disadvantage for SWT is that developers are required to dispose of OS-dependent objects within their application code.

JFace is a GUI library that was developed to compliment SWT and simplify common GUI programming tasks. SWT and JFace libraries are used extensively throughout the Eclipse IDE.

As a Java user interface developer I have used each of these GUI libraries and I find the combination of SWT/JFace my favorite choice because of the native look-and-feel of the components. I also find the SWT and JFace APIs cleaner and easier to develop with than AWT and Swing. My two cents, comments welcome.

In Java GUI Toolkits, Java GUI, java, Abstract Windows Toolkit
Comment (0) Read More...

In my last post I talked about how virtualization changed test lab creation and management. I’m sure the first thing you did after reading the post was download your very own copy of VMWare Server and replace all your hardware with super flexible virtual machines. You’re now basking in the glow of your long term cost savings, marveling at how easy your lab is to maintain, and using some of that extra time and money to bid on my exclusive line of “VMWare Saved My Marriage” T-Shirts available only at my eBay store.

Eventually your boss will notice you’re no longer cursing under your breath and slamming the door to the lab. It’s inescapable. And when the boss man gets wind of spare cycles, he starts thinking crazy thoughts. He starts thinking you now have time for that automation project that’s been on the back burner since 1996. With a heavy sigh and a final farewell to what will inevitably be known as “The period in my life that was great, thanks to Pete Pickerill,” you turn your attention to how you’re going to build a flexible automation framework that runs just as well on your Unix & Linux systems as it does on your Windows systems.

Have I got an open-source project for you! Software Test Automation Framework (STAF) takes care of all the nagging little odds and ends that have very little to do with testing your software. STAF employs a series of pluggable modules (called ‘Services’). Standard services cover most of what you’ll need: file system operations, environment variable management, process execution, logging, and miscellaneous commands like ‘ping’ and ‘zip.’

The command above may seem a little cryptic, but when you break it down into steps it starts to make sense. In the example above:

• STAF is executed on Server1: STAF Server1
• The Filesystem Service (FS) is invoked to copy the file myFile.exe: FS COPY FILE myFile.exe
• The target directory is given: TODIRECTORY /your/dir/here
• The target machine is given: TOMACHINE System2

That’s STAF in a nutshell. You execute the STAF command locally or remotely, you specify the service you want to use, what you want to execute within that service, and provide the necessary variables to complete the task.

Now you may be thinking, “But, Pete! What if the copy fails due to disk space limitations or network interruptions? What if System2 didn’t boot to a usable state? What if it just up and fails for no discernible reason at all?” There, there buddy! It’s alright! STAF gives you very descriptive return codes. What’s more, these can either be returned to STDOUT if you’re using the cli or a scripting interface or as Java Objects if you’re using STAF in a Java class.

Other cool things about STAF:

• Accessible: Java, Perl, Python, Tcl APIS and an Ant task make it very easy to fold STAF into your automation. There’s also an Eclipse plug-in I haven’t had a chance to check out.
• Extensible: Write your own services in Java, C, or C++ to handle testing peculiarities specific to your software.
• Documentation: STAF is managed by IBM and the documentation is the best I’ve ever come across in the Open Source realm. STAF DOCS
• Active Community: STAF is frequently updated and new features and integrations are added all the time. There’s also loads of info in the mailing list. STAF MAILING LISTS & DISCUSSION FORUM

For more examples and info, check out the STAF website, Agile Testing Blog & Performance Wiki.

In Tips, STAF, Software Test Automation Framework, Open Source, agile testing
Comment (0) Read More...

About a month ago I had a conversation with the President of a professional services firm about what was more important to succeed in the market: a good product or a good sales team. Since his background was sales, and mine was in building products, you can probably guess which sides we fell on. The conversation turned into one of those Star Wars vs. Star Trek debates where neither of us could move the other, and we just agreed to disagree.

Which is all well and good, but I have found myself thinking about that conversation on and off since then, and I am now ready to change my mind. Not that I suddenly agree that a good sales force is more important than a good product. But I think both sides miss the point.

The most important thing for success in the market is the customer pain. It won’t matter if you have a great product and a great sales force if the problem you are targeting isn’t really painful to your customer.

A good sales force can sell a mediocre product to a customer if the customer’s pain is big enough, and the reverse of that is true as well. The pain is the key.

So, how do you go about finding that out? Well, two things. First, start with an industry that you know and have worked in for awhile. That will be your divining rod that will point you in the general direction of what is painful enough to develop a product around.

Second, you have to get out there and ask. When Robert and I started Phurnace we talked to more than 100 individual Java professionals (devs, sys admins, architects, etc.). All that we asked them was what was painful about their jobs day to day. And what they told us was that deploying and configuring their applications was really, really painful. That’s when we decided to build some software to help them out.

We didn’t stop asking about the pain, though. We kept following it as we were building the product, going back to those people we had talked to as well as our early customers and ask them what features they wanted and how they wanted them to look and act. We still do that. Every feature we add has to have a customer story behind it which makes it a lot easier to figure out what to put into each iteration.

If you are planning on starting your own company or looking for an idea for a product, there is a great book by a former software exec, VC, and now professor named Rob Adams that I recommend. (Full disclosure: Rob is a friend and on the Board of Directors of Phurnace). The book is called A Good Hard Kick in the Ass. It’s got some great advice on just the kind of market validation I’m talking about.

In customer
Comment (0) Read More...

I just read a blog by Aziz Gilani about “Enterprise 2.0” and his take on how enterprises will respond to the web 2.0 technologies and it’s new approaches. I think it was quite insightful and I agree with him when he comments on some of the basic assumptions by Forrester Group. Aziz writes "Having spent the past 8 years either working with CIOs or within the enterprise I can honestly say that no company will come out and say something along the lines of 'I really need some Web 2.0 in here. Where is my checkbook?' They are more likely to unwittingly stumble into Web 2.0 technology based on improvements to their end to end processes". He is dead on. Web 2.0 is not a defined category like CRM or ERP was and there isn’t one monolithic vendor pushing the concept. It is a bottom-up trend with hundreds of vendors (including free open source tools) that are making it all possible.

He also goes on to mention that configuration of the ever-expanding list of applications will continue to be a huge challenge. Again, dead on. We here at Phurnace see that every day as we talk to customers and prospects. The IT ops and software development tools today talk about “configuration and deployments”, but more often than not, they state “place current deployment process here”. That is the PROBLEM. The current process used by Global 2000 companies is error-prone, cumbersome and often laden with scripts that are fragile or in constant need of attention.

Web 2.0 and Enterprise 2.0 are here indeed, but don’t lose sight of the plumbing. Deployment and configuration management should remain top of mind. Because aren’t we sort of at “Infrastructure 4.0” and it still isn’t simple?

-Larry Warnock

In Web 2.0, Deployment, Configuration
Comment (0) Read More...

When you buy a software tool for your use, you aren’t just buying the application; you are buying the BENEFITS of what it does. Most often, you are really buying piano recitals, little league games and happy hours with your friends. You buy yourself time when you buy a good tool. Because with the right tools, you are in bed, fast asleep, instead of the datacenter at 3 a.m. pulling out your hair because of a deployment error or a server that won’t capture transactions, or whatever. With good system administration tools you get to tackle the hard problems and challenges that made you take your job in the first place instead of the mundane, boring and error-prone tasks.

Unfortunately, “quality of life” has never been a valuable selling point for IT managers and directors. They pay you to keep the network running, deploy applications and configure application servers. The manner in which you perform your job doesn’t matter to them; only the results.

If you aren’t using the right tools, then a huge proportion of your production failures are due to configuration errors. Thus, your entire management team should care about how you perform your job, just like you do.

Simply put, proving a fast ROI is the best way to make a business case for a software purchase and it is terribly simple. ROI, or Return On Investment, is a simple calculation that states the rate offered by an investment. So, if you invest $1000 that provides you a return of $500 per year, then you have a 50% ROI per year ($500/$1000 = 50% ROI). In other words, the “pay back” period for the investment is 2 years ($500 per year, for 2 years = $1000). The rule of thumb in IT spending is that investments need to have a “pay back” of 3 years or less. So to invest $1000, you need to show that you will get more than $333 back per year.

With many tools (could be OpsWare, Build Forge, Phurnace Deliver …), you are provided with a way to avoid costly mistakes and down time. But, determining the dollar amount of those mistakes and downtime can be difficult. Luckily, many vendors (us included) provide an online calculator to help determine those values. And, when you are done filling out the web form, you can create a PDF of your cost analysis to email to your boss.

Recently, one or our customers determined their deployment costs to be $68,365.38 per year and the cost of error resolution was $171,000 per year. That’s a total cost of $239,365.38 per year. To determine their ROI, they simply divided the money saved by our product’s cost. They arrived at a monster 3 digit ROI number and were very happy with their purchase.

Of course, you can always rely on your friendly local software sales rep (like the Phurnace Account Manager) to help you with the purchase process. We all want you to be successful and tackle the truly challenging aspects of your job. So, leave the mundane, boring error-prone stuff to the tool vendors.

In deliver
Comment (0) Read More...

 I’ve been in the enterprise software industry for more years than I would like to admit, although my staff never misses an opportunity to ask “seemingly interested” questions about punch cards, 8 inch diskettes, and what it was like when developers used Pascal. I have witnessed many mind blowing advances in technology, process improvements and creativity. What doesn’t seem to change however, are the fundamentals of growing a company and running a good business.

Granted, many times through the last 24 years, people have claimed and tried to declare “a new model”, one where profits didn’t matter, customer service was to come later, the practice of spending on dreams vs. reality, and betting exclusively on the 1 in 1 million break through that will change the world we live in. Don’t get me wrong -- I love those life changing things – but they ARE 1 in 1 million. For the day in, day out, building of a great company; one that will make their customers always happy and provide value in exchange for dollars – the basics have stayed the same. Regardless of the “wild anomalies” that occasionally appear (remember when the market thought Touthpaste.com would have us all brushing online).

I interact often with investors, venture capitalists, engineers, suppliers, attorneys, salespeople, marketers, customers, industry analysts and the media. They are a diverse bunch and I tend to gravitate towards the optimists vs. the pessimists, but I will say that a common trait seems to be the desire to find “the new, new, new thing”. Not just the new, new thing. That is so 90’s. I am an out-of-the box thinker, as those that know me, can attest. However, some things SHOULDN’T be the new, new, new thing. Things like a) respect for your customers, b) respect for your employees, c) making tough decisions quickly, and d) leading a team vs. administrating a team. These four things are the foundation, in my opinion, of how great companies are built and run. I know, I know, a dude wrote a whole book titled “Good to Great”. It was a study of the habits and traits that were common amongst good companies that became great companies. It is a good read, but I believe that if the basic tenets that I mention aren’t followed, the rest just can’t happen. There, I saved you $24.75. Not really, you should check it out. But if you do, also read “Blue Ocean Strategy”. A good read that discusses changing existing markets. But, I will say again, without the foundation of the four basic tenets, it simply doesn’t matter.

So, if you are starting a business, running a company, or even in charge of a team, remember: 1) respect your customers, 2) respect your employees, 3) make tough decisions quickly, and 4) lead, don’t just administer. It has always been that way, always will. Wow, a Déjà vu moment – again.

In Untagged 
Comment (0) Read More...