Posts Tagged ‘software development’

“Drop the Software Testing Baton”

Thursday, January 17th, 2013

A software tester, with a determined look on his face, walks briskly up to your desk and blurts out, ‘It doesn’t work.’  After you sigh, your mind oscillates between responses of, ‘Okay, let me look into it,’ and ‘What the heck do I do with THAT?’

Developing and testing software should be less of a series of hand-offs between tester and developer, and more of a collaborative, ongoing conversation.  Even with the most well-intentioned of testers, the baton is often passed off to a developer because the tester has run out of debugging options.  FAST has eliminated that baton pass forever.  The testing approach and automation that we used on a recent project played a significant role in allowing us to convert a company’s life insurance policy administration system in only five months.  No one on the project could have imagined this pace being possible without efficient and effective testing woven into the entire project.

Empowering the Team

We created a debugging tool easy enough for everyone on the team to use…

  • A failed test condition was no longer the end of the road
  • What went right, what went wrong and precisely where it went wrong was clear as day
  • Corrections were made simply – using spreadsheets  and configuration changes
  • Painstakingly documenting detailed recreate steps became a thing of the past

With the debugger everyone on the team could,

  • grab the exact xml being tested
  • use it to step through the business logic and rules to see what was happening

Testing & Automation

The test driven approach of FAST 8x and the Test Case Manager are the perfect complement to the debugger.  They both offer tremendous value, FAST 8x automation drives testing efficiency while the Test case manager increases effectiveness.

  • FAST 8x: the test driven approach automatically test APIs, eliminating the need for regression testing the application
  • Test Case Manager: tool for actuaries and the product team to test a variety of permutations using the calc spreadsheet independent of the application
  •  Calc spreadsheet: designed for actuaries, by actuaries, an easy to use UI allows the team to create  their own scenarios  and eliminates their reliance on a technical resource to update code

As we used these tools, it was really cool to watch the traditional software development lines between tester and developer disappear!

Benefits

The benefits of using these tools to debug and test business transactions and calculations were numerous.

1)      Transparency of business processes to the business owner with a user-friendly spreadsheet which is easily traversed

  • This transparency promotes a feeling of trust between the vendor and the client

2)      Business knowledge transfer was a by-product of the transparency of the business rules

  • The tool facilitated business process discussions with the client

3)      Continuous testing of the business logic and rules

  • Resulted in a condensed ‘testing phase’ and quicker deployment

4)      Perpetual vendor reliance was eliminated

  • The client quickly internalized how they could maintain these business rules on their own

5)       Small steps and simple calculations demystify complex calculations

  • Logic is not buried deep in layers of code and errors can be fixed by dragging and dropping the appropriate orchestration step into the right place

As a Business Analyst, the tools were cool and fun to use.  They created a great sense of accomplishment across the team – issues could be quickly pinpointed and then corrected through configuration and I could fix bugs on my own!  And as for the Actuaries being able to create and test their own calculations, let’s just say they got as excited as actuaries get…

After the success we achieved, I can’t imagine a project without it!!!

 

Sharon Amos, Business Analyst

FAST

 

Powering Software Development: Technology and the Virtual Project Team

Wednesday, January 2nd, 2013

If everyone is moving forward together, then success takes care of itself. – Henry Ford

 

Most people believe that successfully completing an Agile project with multiple companies, across different locations is impossible… As technology continues to change where and how we do business, this is no longer a valid assumption.  When implemented thoughtfully, any organization, large or small, can leverage today’s technology to create powerful teams capable of developing great software – faster than ever imagined and at a lower cost.  Using Skype and an HD TV outfitted with a web cam, a company is armed with the all tools it needs to create a dynamic virtual environment for software development projects.  Working closely with a customer in this manner offers significant benefits for both the service provider and the customer -

  • more software is developed accurately the first time because communications are clear and e-mail ambiguity is avoided
  • time is saved as bugs are addressed and resolved immediately because there are no “voice messages left” or “calls to return
  • a unified project team works closely together – this strengthens trust, fosters morale and drives a successful outcome
  • working software is put into production more quickly and at a lower cost

FAST’s Virtual Office

With each customer engagement, a Warp Zone is established – a dedicated project room equipped with a web cam and a large, flat screen television.  Through the Warp Zone, we see our business partners in their normal working environment and they set-up a similar environment so they see us as well.  The cameras remain on all day throughout the life of the project.  Initiating a conversation or asking a question takes a simple wave to the camera.

Working together this way allows us to dig in and understand our customers’ business processes and their needs, so we can provide the best solutions possible.  The reverse holds true as well – customers get a true understanding of the application.  And with regular demonstrations of new software, we receive immediate feedback and can ensure the functionality supports the business needs.

In addition to the benefits related to the project and customer relationship, this structure helps avoid many of the inefficiencies of traveling.  This translates in to soft dollar savings stemming from increased work time and productivity and the improvements in morale associated with less travel along with the obvious hard dollar travel and expense savings.

The FAST model incorporates our offshore development team to accelerate the project timeline.  With Skype and the Warp Zone, a rotating schedule of morning and evening calls with the team keeps everyone on the same page and extends the workday as development continues after the sun sets.  In addition to eliminating many of the quality issues often associated with an offshore team, the Warp Zone’s face to face interaction enhances the daily scrum and software demonstrations while Skype is an integral part of the collaborative development approach fostered by an Agile software development philosophy.

Real Results

Ultimately, leveraging technology to create collaborative work environments enabled us to extend the workday, streamline communication and work in partnership with a customer to convert an entire Policy Admin system in only 5 months.  The efficiencies gained through this approach allowed to us complete the project within budget and in record time.

Getting the Most Out of Your Investment: Three Steps to Revitalize Your Legacy System

Tuesday, October 4th, 2011

Companies don’t need to “rip and replace” large portions of their IT investments in order to gain the set of features they wantBy taking a multi-phased approach to incrementally roll in functionality, organizations can benefit from quicker ROI without the costs and risks associated with “big bang projects”. This multi-step approach is a win-win for business and IT; business can reap the benefits of go-to-market features sooner and IT will be able to adapt to changes more quickly.  Here is our recommended three step approach to revitalizing your IT architecture:

  1. Leverage What You Can: Revitalization efforts have to be carried out with a focus on leveraging your existing architecture. Wrapping your existing assets in web services keeps some of the older technologies in play.
  2. Implement As Needed: Keep it simple and only add functionality that’s really needed. By purchasing pre-built components that augment your existing systems, you can add the functionality you want with minimum configuration and customization.
  3. Rapidly Build New Functionality: Once you’ve decided on the new functionality that you would like to add to your system, we recommend that you rapidly develop these applications using software development automation frameworks such as FAST 8x. By rapidly building SOA-compliant components, you can leverage modern technologies and get the benefits of development efficiency.

Once you have implemented all three steps, you are on your way to fulfilling immediate business needs while achieving long term architectural goals for the future.

Darwinism of Innovation: The Evolution of Automation and the Software Development Industry

Wednesday, August 24th, 2011

In 50 years, will we still have armies of programmers coding business systems for companies? Will it still be necessary?

In the history of industrial growth, the replacement of tedious production processes with automation is essential to the progression of invention and ingenuity. But we seem to have forgotten this key to innovation in software development. We are so caught up in creating new processes, new languages, new “big system” solutions to address the same old problems of tedious code-writing in traditional software development that we forget the true purpose of this industry in the first place – to replace tedium and inefficiencies of the paper-pushing era. We seem to have it stuck in our heads that software development is too complicated to automate.

The key to replacing expensive, labor-intensive and entrenched systems is not by engaging in expensive, labor-intensive big-bang projects, but in increasing productivity, flexibility, and function-leveraging. This is industrial Darwinism at its finest: instead of replacing one inefficient system with another, find a solution that eradicates the costliest, labor-intensive processes altogether. In short, creating dynamic software that will automate technical coding so that the user can focus on the functionality and conceptual use of the software is the true innovative key to the future of the software development industry.

Here at FAST, we have done just that. As a part of a four-person newly hired team of university graduates, we were assigned the daunting task of creating a fully functional application with FAST 8x in just four days, inclusive of training, configuration, building, and presentation. The exercise focused on showcasing how software development automation can achieve what normally would take a team of developers, analysts, and engineers months of code-writing to accomplish. None of us had any previous experience with software development; only one of us had any true technical knowledge of software design, and we were granted access to one engineer to assist us in the configuration process. By the end of the week, we had presented a production ready SOA based set of components that included 40+ database tables, 4 components, full user interface w/20+ business processes, 100+ web services, integration into other applications, 5,000+ test scripts (that are on a nightly regression cycle), technical documentation, and a how-to guide.

This proof-of-concept exercise is a reflection of what we’ve been doing for months on a larger scale with our life insurance client. In less than nine months, we were able to build an entire suite of legacy-replacing components which included 800 database tables, 35 components, full user interface w/25+ business processes, 700+ web services, integration into other applications, 13,000+ test scripts, technical documentation, and a how-to guide. This legacy system modernization process, which would have normally taken approximately three to five years to develop traditionally, is a remarkable step towards the breakthrough technology necessary to take software development to the next level.

If “double dip recession” happens, is your IT group prepared?

Tuesday, August 9th, 2011

I started writing this blog a couple weeks ago…so, now that the market has dropped by 10% it might not look as impressive that I am asking this question.  Obviously, we’re all hopeful that the economy can stabilize and all of our budgets don’t get cut for 2012.  Unfortunately, that might not be the case.

“More with Less”

If you look at Celent’s CIO study from earlier this year, the major theme was: Business expects more from IT. They reference supporting expanding list of initiatives, prioritizing across business groups, escalation of expectations of IT, and balancing cost reduction/capability creation as key challenges and pressures they’re facing.

 

In the last downturn, companies settled for budget cuts equating to less productivity.  Now, I believe we’ll be challenged to get the same amount done for less budget. So, what can be done?

  • Go Agile – if you’re already using an “Agile-like” development methodology, great.  Dive in and examine how you manage your priorities, who the impact players are, and which areas of the process are adding most value.  Eliminate everything else.
  • Get the most out of the tools that are currently available – FAST 8x  (http://www.fasttechnology.com/software/8x/) is an example and I’d be remiss if I didn’t promote our own software.  With FAST 8x, you can build smaller components to solve targeted business problems at a fraction of the cost, time and risk.
  • Avoid big mistakes – Diversify by spreading out your initiatives and deliver value sooner rather than later.  Don’t buy that big packaged core system that is going to be a burden on the entire organization, cost too much money, and risk the farm.
  • Staff reduction is not a “cure all”.  Obviously, eliminating staff and consultants are necessary triggers that can be used to work within a budget cut, but that will most likely compound the problems with the business needing more.  In some cases, you might want to cut even deeper to free up cash for tools and the “right people” to help you navigate through these times.

Pressures and challenges could increase.  Are you prepared?

 

Tom Famularo

FAST

20 Questions to Understand What Your Vendor Means by “Re-Architect”

Friday, July 29th, 2011

I think the term “re-architect” needs to be stricken from our vocabulary.

Whether you’re building a home or a system, the architecture is the first thing you decide upon.  It’s fundamental.  Just as the architecture for a home lays out the blue print for the physical structure, the architecture of a system lays out the blue print from which components and functionality are developed. Before the first batch of concrete is poured or the first line of code is written, you put that blue print in place, and from it every piece of the home or system is defined and developed.

With large-scale systems like policy administration, every line of code is written with that architecture in mind and it is core to everything in the system.  The architecture defines the very essence of the system – it is beyond “foundational”.  Once you go down an architectural path, you might be able to make changes to it, but there’s no re-doing the architecture unless you throw everything out and start from scratch.

So when vendors throw around the term “re-architect”, I think it can be very misleading.  “Re-architect” seems to imply that they have applied some fundamental, structural changes to the software without compromising the system itself; yet, to truly “re-architect” anything would mean a complete overhaul of the architecture that defines it. So, it’s kind of a misnomer.  If they had actually rewritten the system, they would say “we did a complete 100% rewrite from the ground up”.  If they didn’t rewrite it, then there is NO WAY the system is not compromised by the legacy architecture it had.  When you’re purchasing a system – large or small –, there’s a fair amount of legacy architecture and legacy code that comes with the package in almost every case.  You may be OK with that, but you need to have a good appreciation for the extent of it.

Along the lines of finding the “freshness date” or newness of the architecture of the system – as well as just doing some good due diligence – here are 20 key questions I think you need to be asking your vendor as part of the assessment:

  1. When was the last time you “re-architected”?  What parts were not rewritten and why?
  2. Why was the “re-architecting” deemed necessary? And what was the overall impact to the system in terms of % of code rewritten?
  3. What year was the oldest code in your system written?  (I suggest you have the vendor make that a contractual representation and you should get an honest answer.)
  4. For your policy administration system, do you have a monolithic or component based object structure within your code?  If component, do your components reference each other within the code?  Are there database joins that go across your components?
  5. Can you tell me how many lines of code your software is (by language)?  (The purpose here is to gain an understanding of the ratio of newer code to legacy or older code.)
  6. How many customers have converted or committed to converting to this new architecture? For those who have converted, what was the average project duration?
  7. How many lines of code did you write for each of your last three new client implementations?  How long did those implementations take?  (Make sure you can reconcile the lines of code to the duration and that it passes the “smell” test – in other words “if there’s that little code, why did it take so long?”)
  8. Assuming coding changes are required (and they will be), what restrictions are there on using external consultants?   Here the vendor will likely represent that you don’t need to make changes to the core system – do not under any circumstances accept that answer.
  9. How many developers do you have supporting clients offshore and onshore on this platform today?  (Given the low amount of programming you will be told is required, make sure you can reconcile this answer to the answer in #7.)
  10. Am I forced to use your proprietary rules engine?  How easy is it to swap out?
  11. What contractual guarantees are you willing to make about maintaining this platform in the future and future releases?
  12. What is the biggest implementation (# of policies) that anyone who is running on one of your past two releases of the platform we are buying?  (Work to make sure that the answer IS for the platform you are buying.)
  13. List your current clients for the platform I am buying and version of the platform they are running.   (Accept that some clients can’t be named, but insist on a complete list.)  Exactly what functionality are they using and what is the product mix?
  14. Can I have the attendee list from your last user group meeting?  This IS NOT highly confidential and they should be able to give it to you.
  15. Who was the last policy admin customer to go into production for individual life?  Individual annuity?  What were the released version those companies used?
  16. How long did it take your last policy admin customer to go into production (from initial requirements through production)?
  17. Over the past five years, how many companies who have selected your platform where you started projects and the customer never ended up going into production?  (This is information you can learn for yourself in the industry.)
  18. How many policy administration customers do you have that haven’t made a significant number of code changes for customization?  Please name them.
  19. How many policy administration customers have done production upgrades to a newer version over the past five years?
  20. How many customers have terminated maintenance agreement in the past three years?

 

John Gorman

FAST

How Do You Define “Good Productivity” for Software Developers?

Friday, July 22nd, 2011

When I started running in my twenties, I was using a treadmill and doing 10 minute miles for three or four miles.  I felt pretty good about that.  Then I ran a five mile race and I found out that 8 minute miles for a longer run were kind of the minimum for a pretty good recreational runner, so that’s what I ran after that.

Now, my son runs high school cross country and 5 ½ minute miles for a 5k (3.11 miles) is pretty much where you need to be to be competitive.  Benchmarks are set and each year new freshmen come in and shave minutes off their times to meet the established standards.

Basically, how good is “good” is a matter of perspective and benchmarks.  Measuring speed, of course, is very easy and very objective.  There are teammates and years and years of records to compare to, so it’s easy to say what good is.

With software development, we really don’t have a great way of measuring “good” productivity.  Sure, we can measure quality and ability to meet commitments, but how do we know the productivity was good?  And how do you incent people to be good?

How can we tell the difference between the developer who runs the 10 minute miles (and he looks good doing it) and the guy who runs the 5 minute miles?  How do we reward them?

Do you ever feel like your developers are walking at a 20 minute mile pace and passing it off as “running”?

 

John Gorman

FAST