What's New V5.4

The new version of PRPC v5.4 is just round the corner, and is loaded with exciting new features.

Some of the new features are very impressive and immediately usable:

• User Interface related
• List to List Control
• Copy items from one list to another (Whizza veterans, I know that this has been implemented in , however this is an OOB functionality provided now)
• Auto complete is now an OOB functionality
• SMART Info improvements
  now it can be placed on labels & fields without using HTML Paragraph
• Error message customizations – you can now choose to
• Display errors at the top and bottom of the harness
• Display it in a floating DIV, or
• Display it in a configurable section
• Multi level Tabs is now a reality
• Improvements to the form designer
• Create mock ups without defining properties
• Execute flows in DRAFT mode.
• Branding / Skinning of applications –
  there a new wizard that enables one to customize fonts, colors and images
  of the application


• “This operator is using Application-based configuration; you may not specify
  secondary Access Groups.” This error is a thing of the past – you can now
  Assign one or more “Application Based” access groups to an Operator ID
• Cross browser code – finally one can use the generated application on Firefox. Preflight
  can check for cross browser compatibility issues.
• Reports
• Joint List view and Summary view
• you can use the wizard to modify existing reports
• you can now use the wizard to create reports on any class within a class group
• Correspondence
• send meeting requests!!
• Inbound email now handles Auto Reply and
  delivery Status notifications
• Handle inbound email attachments
• SOAP
• Axis 2.0 in addition to Axis 1.2.1 support
• Attachments support
• Handle SOAP errors
• Circumstance rule improvements
• Class Structure! – finally a view to “see” the class structure right from the @baseclass
• Audit trail
• Control which events trigger audit trail
  
• Obj-Browse, Obj-List-View,Obj-Filter, Text-Normalize - new Activities for common tasks
• Selective import of rules from zipped exports
• Rename classes and rulesets!
• Testing framework updates

Attend the webinar to learn more.

Requirements Analysis Problems

In an earlier post I'd lamented about the problems in managing requirements, this post probably reads as a prequel to that one. What are the real problems when it comes to requirements analysis?


Meryl K. Evans of the lockergnome identifies 5 specific issues:

1. Customers Don’t Know What They Want
2. Requirements Change During the Project
3. Timeline Trouble
4. Communication Gaps
5. Customer Organization Politics

True, customer is King. However, everyone has heard the Hans Christian Andersen tale the emperor's new clothes.

Who tells the customer that he is wrong? The answer is embedded in another question. Do you even know that the customer is wrong? And when you say customer, who are you referring to?

As always the "two sides to a story" paradigm holds here. Business knows business. Technology speaks technology. Some of the requirements are never ever seen by the business user who is detailing his requirements - these are system requirements, file transfer protocols, security measures, compliance issues, hardware sizing, upstream applications, downstream applications. Showing mock-up screens and having walk-throughs and spewing tomes of documentation will get you a business buy-in, however beneath and beyond the snazzy drill-down reports and ease-of-use-navigation and pretty and a pie user interface lie the incompatible data formats, tucked-away-in-binary information , firewall issues, port problems, network latency, hardware scaling and application performance issues.

Ask any developer - can 'this' be done? and he will tell you... it 'caaaaaannn' be done, buuuuuuuut.... The length of the 'can' and the drag of the 'but', translate loosely to: Sure you 'm0&@#', I'm an engineer and this is code and I can get it done. However, do you realize the number of lines of re-coding and hours re-testing effort it takes to have that silly nice-looking jazzy useless piece of junk information on the screen? And, do you even begin to fathom the performance impact this is going to have on the downstream applications that use the data feeds from this system, and the weekend batch is going to take at least a couple of hours more? As you swivel nervously in his cubicle, waiting for him to say some thing more.. he ends the mystery abruptly by saying: No.

Can we involve the IT during the functional phase of requirements, ideally yes. Do they have to sit in everyone of the meetings? Probably not. However, before you go in for the final grand sign off from the 'business', make sure you have a tacit approval from the development. Goes a long way in avoiding surprises later.

I've noticed in several instances that accommodating requirements changes from the IT are more time consuming and project impacting than those from the business. Business can be 'made to understand'; whereas, IT issues are more immediate, critical and non-negotiable. Hey, if a particular entry violates the primary key, then you can't really do anything to code around can you? If the security policy will not allow users have then lower their browser security settings, you can't have the fancy browser based copy-paste functionality can ya?

This issue is compounded when multiple mini-clients exist within the client organization. And if there exist political friction between the client's teams.. ouch .. you are sitting on a live mine.

Time solves everything. Except when it's solving time related issues. Study the requirements and share the time-line with the customer. If you don't have any room for over-runs and slippages, fine - but, tell the client that you are running a tight schedule. This might help him, help you prioritize. If a project has even a minor chance of slipping time lines, then the chances are it will. and the earlier you the tell the client, the better it is.

Happy Diwali everyone!!!

Happy Diwali!!! Have fun everyone.. and play safe!!!

Breaking Down Software Development Roles

As a IT professional, I've often found myself at a loss when I've had to explain my job concisely.

Usually following the informal pleasantries, including hellos, name exchanges and handshakes is the dreaded "So, what do you do?"

Um' I'm an IT professional.

Okay, but what do you do?

I um.. develop software.

Develop software?

Well.. I do requirements analysis, design, architect, develop, document, test and deploy software applications based on customer needs, while working with various vendors and integrating with other applications and co-ordinating activities with offshore team members.

Huh?

I write code.

oh!

By this time, the pleasantries have ceased to be that, and the other person either looks at you and your family pitifully or warily.

The truth is that the software developer of today is expected to perform all these roles. Internet.com, has tried to break down the software development roles as they exist today.

Software development, the paper observes, is done differently at every organization, and recognizes that the process that one organization or person uses to develop software may not work perfectly in all circumstances.

While environments will change and with that the process that are being adhered would be adapted either marginally or dramatically.. however the multiple and multi-faceted practitioners of the fine art of software engineering remain largely the same - for the requirements are the same - There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. Although each of these processes may change to some extent based on the programming models and tools being used, fundamentally there are some roles, which every process has in one form or another.

One person may be filling all the roles or a handful of the roles, or one very specific role. Despite
this there is a need for all of the roles -- each serves a purpose.

From Subject Matter Experts, Functional Analysts, Solutions Architect, Development Lead,
Developer, Quality Assurance, Deployment (Deploy), Training, Project Manager, to the Development Manager, each role has a set of critical skills required.

Download the paper from here. (free registration required)

The Future of Software Development

Software development has come a full circle states Alex Iskold in a scathing, pull-no-punches broadside upon the Waterfall model.

Read it here: the future of software development

Alex states that arrogance was the main problem with the waterfall model. The arrogance he argues came from the fact that we believed that we could always engineer the perfect system on the first try.

37 years ago, W. W. Royce published a sequential development model, coining what is now known as the waterfall model. This approach applied the insights from mature engineering disciplines (mechanical, civil, etc.) to software. The idea was to construct systems by

1. first gathering requirements,
2. then doing the design,
3. then implementing it,
4. then testing,
5. and finally getting it out the door in one linear sequence.

Ironically, Royce actually argued in this presentation that this was a flawed and actually proposed what is known as iterative design.

37 years - a lot has happened, and we have come a long way and (hopefully) have learned a lot about making software.

However, in the real world, (and in other unreal places that I happen to work in) software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. This effect is compounded by the accelerating pace of business.

Older development methods completely fail to address business needs. The Waterfall Model is rigid and unrealistic and incapable of rapidly adapting to and keeping pace with the changes to the business.

Using the Waterfall Model, these

1. changes were impossible,
2. the development cycle was too long,
3. systems were over engineered and
4. ended up costing a fortune,
5. and often did not work right. ;-)

In nature, dynamic systems are not engineered, they evolve.

• Build small and then add on.
• Model the Happy day scenario. Leave the esoteric corner cases for another day, another release.
• You cannot and must not code for *all* the weird and *potential* use case scenarios
• Build pluggable frameworks
• Design to integrate
• Leave the system open, and flexible

The solution to achieve these niceties, it appears is an age old one. In 1975 - (a few years after the Waterfall term was coined), Fred Brooks famously propounded that "Adding manpower to a late software project makes it later" in his book titled The Mythical Man-Month: Essays on Software Engineering. However we see this mistake repeated everywhere; and in every project that is going sour. "Throw-more-resources-at-it", will probably get you a few more months out of your aging PC - but hardly ever speed up the project.

Alex evangelizes the adoption of agile methodology as proposes that in the future, software will be developed by "Just a Few Good Men" and provides a simple overview of Agile Software Development Principles:

• Have Fun
• Focus on Simplicity
• Adapt the code
• Embrace Change
• Get feedback
• Refactor
• Communicate
• Release Often
• Test

.. and concludes with his forecasts for the future:

• High-quality, passionate software engineers will be in very high demand and will make substantially more money. - Good!!!
• The developers who do not have great programming skills are going to have to look for jobs elsewhere. - hmmm... why are they in this industry in the first place?
• The changes that we are witnessing today in the social software market are going to reach the enterprise level. - SAS? the Web is the computer?
• Software off shoring will make less and less economical sense. - why so? does agile software development going to make the world less flat?
• Computer science is going to remain a highly competitive and prestigious field. - sure hope so.

While I agree with Alex's theme in general, with respect the Agile methodology adoption, I fail to see why off-shoring would get affected by this; Unless this this is was just a general comment.

On this topic, I had a brief chat with a colleague of mine, another proponent of the Agile methodology himself, and he argued

1. it would not be possible to have synergistic agile teams across the seas and across timezones.
2. Agility would be impeded due the overhead of heavy documentation; people would not understand the business properly otherwise.
3. it is not cost effective to have several delivery dates from offshore
   

I smiled in reply - it will evolve.

SAP to acquire Indian BRMS company Yasu tech

SAP announced on Wednesday that it is acquiring privately-held Hyderabad, India based Yasu Technologies, which creates business rules management software.

Yasu's flagship product is the QuickRules BRMS, launched in early 2000. The deal is designed to boost SAP's business process management (BPM) offerings and will be tucked into SAP NetWeaver, which channels the ebb and flow of data to software applications via SAP's back-end middleware.

The India-based company was founded in 1999 and has just over a 100 employees. Started by 6 entrepreneurs, it boasts of some of the best talent in India’s IT industry, with over 70% of the product development team comprised of IIT alumni.

The Yasu announcement comes just a little over a week after SAP announced that it will acquire Business Objects in a deal valued at more than $6.8 billion, its largest acquisition ever.

Help Line - More signs of out-sourcing

I was feeling a bit depressed the other day, so I called the Help Hotline.

I was put through to a 'call center' in Pakistan.

I explained that I was feeling suicidal.

They were very excited at this news and wanted to know if I could drive a truck or fly an airplane....