Who’s On Phirst

So, as I am sure any reader of this is aware, agile programming methodologies (like Extreme Programming (which for some reason is called XP, not EP)) are all the rage nowadays. Seems like everyone is doing it, from small scrappy ones (ahem) to giant behemoths. Personally, I’m a big fan. Sure, it’s no silver bullet, but it beats the crap out of the age old waterfall projects I worked on back in the day.

Here at Phurnace we try to be agile. We do mostly 4 week iterations, which typically include 1 week of planning and 3 weeks of “doing.” All told, it works pretty well. One thing that we do a bit differently than any other place I work at though is how we approach scheduling – which, shocking, is the subject of this entry. Using this scheduling methodology we have hit the date for 20 of our 23 iterations. Once we were a day early, and twice we were a day late. Personally, I think that’s pretty awesome.

Here’s how we approach scheduling. For those interested, this approach is based in larger part upon work done by Dr. Eliyahu M. Goldratt and his Theory of Constraints (TOC) and Critical Chain Methodology. That, in turn, is also largely based on operations theory and the Central Limit Theorem. We don’t slavishly follow Dr. Goldratt’s methodology, but we borrow heavily from it (so credit where it is due). If you are interested, read Dr. Goldratt’s book The Goal for an intro to the TOC and Critical Chain for more depth on the Critical Chain Method.

Now that you are suitably impressed by my ability to hyperlink, let’s get into some specifics:

Because we are good and agile, all our planning starts with a customer story. You know the drill – “The customer should be able to something when they something in order to accomplish something else.” Stories for the most part come from products land, but anyone can write one. Well, except sales. We tried that once. Let’s just say boundaries are there for a reason. We use Xplanner to organize our stories.

So, at the beginning of the iteration we sit down and figure out what stories we would like to work. We always choose too many stories, but the temptation to “add just one more” is too much to resist. We also prioritize the stories, and try to build one to three central “themes” of the iteration. But once we have the stories selected we present them to Dev. Dev has a week to estimate and plan how to get those stories done.

The thing about estimating development (coding, testing, etc.) work that’s hard is that for the most part you have never done the task to be scheduled before. I mean, sure, you have developed software before; but, you have never developed this software before. If you had, you wouldn’t need to schedule it, right? It would be done already. So, for the most part software estimates are swags – best guesses. Sure, you can do research to improve the swag, but basically it’s still going to have a lot of uncertainty. And it’s that uncertainty that creates one of the big problems with how software tasks are scheduled.

Let me take you through the process that I am used to in a software shop. It goes kind of like this:

Product Manager: “Hey guys! I am super pumped about this next release! This time we are going to add support for 3 new platforms, and also add 2 new UI elements, and fix those 3 critical bugs we shipped with on the last release. So – how long do you think that will all take?”

Developers (thinking): 10 weeks. (This means they think 7 weeks, and give themselves a 40% “fudge factor.”)

Product Manager: Ok. (This means he is planning for 15 weeks, since projects are never on time.)

What’s going on here? The interesting thing is everyone involved is calculating risk, but no one is actually quantifying it. The only thing they are quantifying is an “expected” date – but there’s no analysis as to the underlying risks.

The good news is there are lots of ways to assess risk in estimates. PERT is a good one – and we are going to use a part of PERT to calculate the risk of each task. But PERT has some limitations that we are going to try to jump over. Realize, what we are doing by calculating risk is actually building a probability distribution of the likely completion times of each task.

In Part Two of this series we will go through the exercise of calculating “risk” in software projects, and give a real world example from Phurnace to see how we do it. In Part Three we will take that example and build a schedule that takes into account both actual completion dates as well as the riskiness of the tasks.

In Untagged 
Comment (0) Read More...

This will be exciting news for those of you waiting for the addition of our support of WebLogic 9.2 and 10g. It is now here! Read the press release below for the details:

Phurnace Announces Support for Oracle® WebLogic 9.2 and 10g

Web Application Deployment Software Now Available for All Supported Releases

AUSTIN, Texas — November 21, 2008 — Phurnace Software, Inc., the Java application deployment company, today announced that its flagship product, Phurnace Deliver™, now supports Oracle WebLogic 9.2 and 10g. Phurnace Deliver currently supports WebLogic 8.1, as well as RedHat JBoss™ 4.2 and all of the market available versions of IBM® WebSphere® web application servers. Phurnace Deliver will automate the migration of applications from older to newer versions of WebLogic, therefore speeding the upgrade process for WebLogic customers.

“Phurnace continues to add support for all of the versions of the leading web application servers”, said Daniel Nelson, vp of products at Phurnace Software. He continued, “WebLogic customers have been asking us to support the latest version, 10g, now that they know Oracle will be supporting it far into the future. Deployments of applications as well as migration upgrades will now be seamless for these users.”

Phurnace Deliver provides comprehensive support for IT staff and developers during complex enterprise Java deployments to decrease errors, streamline deployments and avoid the downtime and outages that come with manual or script-based processes. The current user approach of paging through the console or building cumbersome scripts can be reduced or eliminated with Phurnace, therefore freeing up limited IT resources for more value-added tasks.

Phurnace Deliver provides functionality for users including:

• Automated deployment of applications and their required configuration changes
• A “deployment packager” to quickly bundle changes to configurations and deploy them network-wide
• A “migration wizard” for ease of application migration from one version of app server to another
• Ability to compare configurations across environments to aid in troubleshooting
• Direct integration into industry standard source code repositories (e.g. Subversion™, ClearCase®, CVS)
• Direct integration with build and operational systems (e.g. IBM Rational® Build Forge®, HP Server Automation (Opsware), BMC BladeLogic)
• Eclipse RCP graphical user interface and command line interface (CLI) options
• Support for a wide range of web application servers (IBM WebSphere, Oracle WebLogic and RedHat JBoss)

In WebLogic
Comment (0) Read More...

Hi all, we just opened registration for an upcoming webinar we are doing with Forrester Research titled Data Center and Deployment Automation: Stop the Scripting This should be a great session so please join us on December 11th. Details below:

Please join us for this informative webinar featuring Glenn O'Donnell of world-renowned Forrester Research. He will articulate that there is a "much better way" than scripting for repetitive I.T. tasks and that many processes in the data center are now automated. Glenn will also discuss Data Center Automation market trends and share his direct experience with global IT shops in this area.

Phurnace Software VP of Products, Daniel Nelson, will follow up with a brief presentation explaining how application deployments can be automated with specialized software vs. hand-crafted scripts. Daniel will discuss auto-configuration of web application servers and how major corporations are now automating the movement of J2EE apps from dev to test to production.

Date: Thursday, December 11, 2008
Time: 11:00AM - 12:00PM CST
Location: Online
Presenters: Glenn O'Donnell, Senior Analyst at Forrester Research & Daniel Nelson, Vice President of Products at Phurnace Software
Registration: Please register here to reserve your space.

In Scripts, Deployment
Comment (0) Read More...

As my internship comes to a close I look back at the experience and reflect on what I've learned. There has been so much, I won't bore you with all the details, but instead I will summarize the technical skills that I've gained.

First off, some of the main skills that I've learned are related to the Linux command line. Most OSes I've rely on a GUI that gives you point and click buttons. Basically you aren't forced to use command lines day to day in college. But being able to work with some Linux command line gurus I've seen some crazy grep commands. Here's a cheat sheet that's helped me along the way.

Secondly, I've programmed in Eclipse before, but not as extensively as here, my experiences up to this point were simple class projects. I only needed to know some basic debugging and navigation skills. Not here. Now I've learned how to navigate through code fairly quickly to find what I need. Here's another cheat sheet that's helped me.

Next, before I came here I didn't have a clue of what an application server was. Let alone, actually working with one. I've gained valuable experience being able to work with BEA Weblogic, IBM WebSphere and JBoss. I wouldn't have learned this in a common computer science class and have I have also learned that documentation is your friend!

Finally, there are random things here and there that you would pick up from just working with a development team. Like working with VM images, experiencing the day to day operation of software development and taking in all of the information that I can, like osmosis, from my amazing coworkers.

In Untagged 
Comment (0) Read More...

Being the honorary dev environment manager at Phurnace is a lot like being the employee of the month at a pig farm. Sure it sounds prestigious, but it really just means that you are able to deal with a lot of crap and you never mention how much it stinks. On the plus side, holding this title has given me a lot of insight into what our customers experience on a day to day basis. J2EE web application environments are difficult to manage. While the common commercial offerings provide great performance and availability for your web applications, the management and configuration of these platforms seems to have escaped the consideration of vendors for the most part. It doesn’t take long to become hopelessly mired in a deep directory tree digging through XML or a labyrinthine administration console that might as well be written in cuneiform.

The inclusion of Properties File Based Configuration (PFBC) in WebSphere 7.0 signifies a change in how platform providers view configuration challenges. They have recognized the pain and are now starting to address it. The aim of PFCB is to make the configuration data more accessible to users by storing it in key value pairs that are a little easier to read and understand than XML might be. The interface between these properties files and your application server configuration is a command line tool aptly named the Properties File Based Configuration Tool (PFBCT). The PFBCT is an extension of the wsadmin scripting interface and has 4 main modes of operation:

• applyConfigProperties - applies properties in a specific properties file to the configuration
• deleteConfigProperties - deletes properties in your configuration as designated in a properties file
• extractConfigProperties - extracts configuration data in the form of a properties file
• validateConfigProperties - verifies that the properties in the properties file are valid and can be safely applied to the new configuration

On the surface this sounds great. We have the methods we need to collect, test, update, and delete configuration information, and it seems pretty straight forward. This approach is similar to the approach of Phurnace Deliver because it abstracts the configuration data from the configuration mechanism. This makes configuration data easier to propagate in a large environment or port during environment updates.

Ultimately, I have to chalk this one up as a swing and a miss for IBM. PFCB (and its associated ‘T’) fails to simplify configuration management. In light of the following, I feel it complicates it further.

• The implementation is woefully inefficient - One of our fundamental beliefs as a company is that SCRIPTING IS NOT THE ANSWER and IBM has not given us a reprieve with this new tool. The implementation relies on the CLI and is very reminiscent of the wsadmin interface. In fact the only palpable difference is that the wsadmin syntax has been replaced with a different, but equally confusing PFBCT syntax. For example, to create a properties file for a server object you’d have to execute the following using the tool:
  AdminTask.extractConfigProperties('-propertiesFileNserver1Config.props, -configData Server=server1')
• The abstraction stops at resource attributes. You’ll notice from the example above, the object ‘server1’ must be explicitly declared in order to act on it. So if you have dozens of application servers and you need to collect configuration data from all of them, it requires dozens of individual PFBCT executions. In Phurnace Deliver, you just need to supply connection information and Deliver interrogates the server, gives you a choice of nodes to work with, and you’re off to the races, collecting the configuration data for all servers on the node or a subset of servers that you define. You also can get all the configuration data from Cluster, Cell, and Node scoped resources in your environment in the same shot.
• PFBCT supports only the most commonly used configuration attributes. Most notably absent are the attributes pertaining to Service Integration Busses.
• Absolutely no reporting of changes made. Nothing has been done to provide administrators with a summary of the changes made on execution. Instead, the PFBCT assumes you’re cool with “no news is good news.” When your company’s point of transaction is on the line, is that really sufficient?

On the one hand it’s heartening that IBM recognizes and has started addressing the problems associated with managing complex application server environments. On the other hand, this solution is anything but complete and seems like little more than an afterthought. I’ll be interested to see where they go from here. In the meantime I’ll stick with Phurnace Deliver.

In WebSphere 7.0, Properties File Based Configuration PFBC
Comment (0) Read More...

Mark Twain is reported to have once said, “Even if you are on the right track, you will get run over if you just sit there.” How true today when talking about this troublesome economy and I.T. operating plans. The times require action, not just thoughtful direction. I.T. executives across the country have their email boxes full of directives, notes, and “just a thought” memos about cost cutting and doing more with less. Hiring is frozen or worse, cutbacks are being planned. But, the customer-facing applications must continue to be updated at a record pace. System uptime must be maintained or increased to 99.999999%. Is that six sigma or eight? I have never really been clear about that.

Cost containment has always been top of mind for I.T. executives, but right now (post election day, pre-end of the world prediction date by Sequoia Ventures) it is the topic of almost every meeting. So what is a CIO to do? Post internet bubble, costs have already been pulled out, staffs have been reduced and they have never really grown since 2002. Where is the fat? Where is the waste? Where are the savings?

Simple. The answer is Automation. Find manual processes and automate them. Find teams of I.T. people doing the same task month in and month out and that is a target for automation. I, of course, think that automating application deployment is a key. The point however, is to look at all of your repetitive tasks and consider automating them. There are savings there for sure.

Damn, this blog entry is sounding a lot like my last few. But I continue to be amazed at how many manual processes and hacked together scripts are holding corporation’s I.T. together. It seems so Rube Goldberg to me. (Look it up, the old cartoons where the cat chases the mouse which knocks over the glass and spills the water so the waiter slips and throws his tray that hits the light switch …). The answer isn’t a new-fangled SOA-based cloud computing grid that has virtualized instances of web 2.0 socially networked avatars. It is getting back to basics. Define the top priorities. Stop everything below item 5 and then automate where you can and take the time to set realistic expectations with the line of business owners on what is possible and what isn’t.

In Untagged 
Comment (0) Read More...

A Portal represents a web site that provides a single point of access to applications and information. IBM WebSphere Portal is highly complicated software that enables companies or organizations to host their own portal.

WebSphere Portal offers two main tools to help manage WebSphere Portal configuration: XMLaccess and ReleaseBuilder. Besides automation, the major benefit of XMLAccess is its ability to update pages and portlets without losing user customization. If you perform your updates via XMLAccess, any user customization to a page or a portlet is retained because the object IDs are retained. Release Builder, helps you deploy new applications from staging to production. It captures the differences between two versions of the configuration and builds a delta XML configuration file that can be imported in the production environment to represent the new deployment.

However, neither of these tools solve the problem of updating the theme or skin artifacts or updating the portlet .war. WebSphere Portal does offer a means to update the wps.ear file with the new theme or skin as well as deploy new portlets. This common task requires the administrator to learn two additional tools such as wsadmin and wpconfig.

Most WebSphere Portal sites use the Personalization features offered. Again, WebSphere Portal offers yet another tool that allows the administrator to stage personalization rules from one server to another. This tool is called pznload.

At this point, you are probably getting the sense of what is required to manage WebSphere Portal.

We are not done. Almost every WebSphere Portal deployment relies on at least one enterprise application deployed to WebSphere. Therefore, upgrades to portlets sometimes require upgrades of the Enterprise application that supports the portlet. Now, the WebSphere Portal administrator needs knowledge about WebSphere administration too.

It is easy to draw a conclustion that because WebSphere Portal encompasses so many topics, the management of WebSphere Portal is extremely difficult, especially in a fault-tolerant, scalable solution.

We at Phurnace experienced these difficulties first-hand. From a developer's point of view, this pain was the driving force behind creating a new product, Phurnace WebSphere Portal Deliver. Phurnace WepShere Portal Deliver leverages each of these tools that IBM provides internally. Phurnace utilizes the same technology and tools that a WebSphere Portal administrator does today. However, it offers additional intelligence around working with these tools, handling errors, and even working around defects in ReleaseBuilder. Finally, with Phurnace, the processes can be fully automated and after deployments are complete the user is left with a report detailing what changed. Therefore it is faster, easier and there is an audit trail that is automatically produced. With Phurnace WebSphere Portal Deliver, the administrator only has to learn a single tool and that tool will make their jobs a whole lot easier.

In WebSphere Portal xmlaccess, WebSphere Portal
Comment (0) Read More...

Installation testing on Windows can be a chore if you don't know what your application under test does to the system. In addition to laying down files in the "Program Files" directory (or a user specified directory), a Windows application will typically put installation files in a temporary directory. It might also install DLLs in the Windows directory, or create or update entries in the registry. Knowing what an application's installation does to your system is especially important when you get to testing the uninstallation. Fortunately for those of us in the software testing profession, there is a handy utility called RegShot.

The first thing we want to do is start with a fresh Windows system that has never had the application installed on it. (This is where Ghost or VMWare is extremely useful in your test lab, by the way.) Install RegShot. I used version 1.8.2. Start RegShot and set your Scan Dir if you want to scan the hard drive in addition to the registry. Now select "1st shot". You will get a context menu with Shot, Shot and Save, and Load. I choose Shot and Save, as this will save a registry hive file that can be loaded at a later time.

When it is finished scanning, you will be prompted to save your hive file. We are done with the first stage.

Now we install our application that we are testing. After installation is complete, select 2nd Shot. When it is finished, save the second shot. Now you can compare the two by selecting compare. You will then be presented with a report that tells you what registry keys and values have been added, modified and deleted. The report will tell you similarly for folders and files if you chose that option.

If you want to test uninstallation, click the Clear button. Then load your second shot with the 1st shot button. Uninstall your application. Then make a third shot with the 2nd shot button, and compare the two.

In Untagged 
Comment (0) Read More...