Things you wish your Software Product Manager knows - Requirements

Most product managers/ops managers don't really know much about software developments but they do know management.

A good example is the word requirements. Most of the time the product manager will spend some time crafting out the business requirements/operational requirements in order to get management approval to go ahead with the project. After getting approval the product manager would pass these business requirements to the development team and probably say something like,

Manager : "Here are the requirements now go build me something".

Development team : "Now we need to do some requirement gathering"

Manager : "What do you mean you need to gather more requirements, I took a few months asking all the managers what the requirements are, I already asked all the ground users what the requirements are, don't waste anymore time , now go build me the system. "

and so on....

That's more or less what happened to me, then as my team around asking end users if they heard about my project and what's the aims are, no one seems to know much. So every user meeting we went to we gotta explain what the vsion of the project was and what we think their roles in the project is and how they can contribute.

So what product managers should know that there are many types of requirements, namely business, functional, user and system requirements. And they are all needed in order to build a system. What the product manager wrote to management in order to get the project moving is usually a mixture of Business and User Requirements.

So what are the various requirements that you need?

Business/Operational Requirements - Usually stated in terms of what must be accomplished to achieve value to the business.

User Requirements- Describe what the users are able to do, usually model thru use cases or user stories. Examples would be like - "User would be able to make a reservation:, "User would be able to edit his personal information"

Functional Requirements - What the system needs to do in order to fufill the User Requirements, like we need to have logins tied to the LDAP server, or we need send email notification and so on. Things the developement team might need to build in order to satisfy the use cases.

Tomcat and JRockit

One probelm with Tomcat is that if you deploy and app too many times you will hit a java.lang.OutOfMemoryError: PermGen space sooner or later. This is especially prevalent if you use things like Hibernate, Apache commons logging.

Here's the way that I setup Tomcat to run with JRockit.

open setclasspath.bat in <Tomcat Home>\bin

Put in the follwing lines after the last comment from the top

set JAVA_HOME=<jrockit home>

Just run tomcat using the startup.bat file and go to the status page at http://<ip>:<port>/manager/status you should see a table "Server Information" with a heading JVM Vendor as Bea Systems,Inc .

I tested this with Tomcat 6.0.18 and JRockit 1.6.05_b13

External Links:

Info I found on running JRockit and Tomcat as a windows service.

Some links on the Perm Gen issue.

Crashing Tomcat

Preventing Java’s java.lang.OutOfMemoryError: PermGen space failure

Memory leak - classloader won’t let go

Web frameworks and Ajax

What I wanted to share today are some criteria that you might want to look at when looking at using Ajax components (Extjs, Dojo) and Web Frameworks like Spring, Struts.

How we decide on the Ajax component/framework the first time round?

Simple ... we just looked for the best and sexiest one around ... and we settled on Extjs. Seems to offer all the componets we wanted.

So we tried putting Spring MVC and Extjs to work together.

After starting to program...

After programming for about 2 months, we found somethings that you probably should try with each of the frameworks before you decide.

1. Submitting forms

Find out how the ajax library submits forms, for example Extjs submits forms using the "ajax" way, and expects the reply as a JSON string indicating success or failure, while Spring does it the traditional way that is through GET/POST and you are also able send Java objects and get back Java objects. So when you merge these 2, you need to either make Extjs send as a normal post/make Spring send back spcific JSON strings.

We went for the first approach, so we were unable to get Spring's simple form controller to get back objects so we just use the normal HttpServletRequest object to read the ParameterMap and form objects from the map.

Take note also that not all components can be sent back as a Post response. Things like Grids in Extjs can't be sent back automatically so we had to use hidden fields and set them to the Grids data (in JSON) to send back to the controller.

2. UI Components

Things that looked good in demos,  is sometimes  not too easy to replicate and to decipher, our first approach was to try and modify similar layouts to our needs but then we found out that most of the demo code resides in javascript files and  not embedded that made debugging abit harder for us. And the code was getting messy with comments here and there and debugging was painful.

So we did a bottom up approach where we slowly tried to learn and build the UI and we embedded most of the UI code in the jsp page itself and used firebug extensively to debug. It took a lot more time but hey we understand how things work better.

3. Cross Platform

The main use of such Ajax frameworks over coding your own is most of them cater for cross browser compatibility but its still up to you to fully test your website.

We found Firefox to be more forgiving in terms of certain mistakes where in IE that page won't even be rendered. Things like additional commas when defining array and missing variables are more likely tolerated in Firefox than in IE.  So test at least on IE and on FireFox and on as many browsers you can get, u maybe surprise at the errors that you get.