1. Use caching wisely: Use caching without hesitation. But cache different data for different amounts of time, based on how huge it is, how long it remains unaltered and how frequently it is accessed. Choose the appropriate caching technology or mechanism.

2. Minimize server round trips: Minimize the number of hits to the server during an operation. For instance, while loading data or executing a set of operations.

3. Use memory sparsely: While using memory-critical system resources, stick to ‘Acquire Late Release Early’ principle. For example, opening web/DB connections and creating IO streams. Also determine the data required for the current page and current request and load only as much.

4. Use lazy/ asynchronous processing whenever possible: Always reduce the amount of workload for a single request by opting to delegate part of the work to a background process, by opting to make an external system’s processing asynchronous or by doing the processing later.

5. Use remote invocations selectively: Remote invocations are very expensive and have great impact on performance. Hence use them as selectively as possible.

6. Profile your code frequently: Use performance testing tools like SQL profilers and code profilers to benchmark your product’s performance. Also deploy some code analysis tool(s) in parallel, and make sure your code passes through all performance parameters in the project-specific checklist you have arrived at.

7. Audit performance: Monitor and track (log) performance-related data at chosen parts of the code consistently to monitor performance.

8. Benchmark your product for performance: Test your application periodically with large quantity of data and use appropriate tools to benchmark your application for performance.

“It is not enough to do your best; you must know what to do, and then do your best.” – Edwards Deming (American Quality Guru)

1. Identify the right set of Test Data for testing:
Produce the right set of test data for testing. This test data (range of positive and negative values) will help you uncover the issues quickly

2. Make the test environment identical to production environment:
Have a thorough understanding of the test environment and adhere exactly to the same hardware/software requirements replicating the production environment (like operating system, database, application server, browser, patches etc.)

3. Complete unit testing before you do integration / system testing:
Test your units first, and once you’re convinced that they have no errors, start integrating them slowly, testing in groups of two, then threes, etc., until you finish testing the entire suite

4. Focus on Numbers:
Always collect quantitative data during different phases of your testing.  During performance testing, get clear and exact numbers on the response time, throughput and resource utilization goals

5. Use 80/20 rule or Critical Path Testing when required:
Identify the right testcases that will provide maximum impact when testing the application. Identify specific test cases which will prove effective during multi-platform testing. For example, identify a page that has maximum controls and run them once in all the browsers

6. Test from the user’s perspective:
Focus on testing the functionality from an end user perspective. Discuss with the product management team in understanding how they approach the application. Interact with product support teams to know customer support issues which may give you idea on issues. Focus on specific areas of testing based on application needs. For example, security is of paramount importance when testing credit card or banking applications.

7. Perform Root Cause Analysis for Defects:
Mark defect as unit, functional, integration, system, etc at the time of filing them to perform effective root cause analysis.  Perform root cause analysis periodically. Put in a prevention mechanism to avoid such defects in the future.

During execution, do not ignore failures. Troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem.

8. Write clear, descriptive and unambiguous bug reports:
Be precise while writing the defect summary and its description.  While writing the description, document it clearly and make sure that the developer does not misinterpret it. Attach snapshots wherever required

We kicked off a new Producteering forum initiative recently and hope to continue doing Producteering interviews with senior software executives, product development managers and thought leaders in the ISV space on a bi-monthly basis. 

Here are some excerpts of our first interview with Steve Nordmark, VP – Technology & Product Development, Thinkronize.

About Thinkronize: They are a leader in the digital delivery of K-12 educational content in the US and are dedicated to enhancing the education of youth with highly effective technologies in a safe, relevant, easy-to-use format. Thinkronize and their netTrekker search product suite has been honoured over 20 times for their contribution to education. The company currently serves over 12 million students in all 50 states of the US.

LISTEN TO THE INTERVIEW PODCAST

Selina: Can you give us a quick insight into the school educational system in the US and what role technology plays in it?

Steve: Sure, I’d be happy to. Over the past 13 years, I have worked in the educational space, primarily K12. Within the US education system, technology and the way I focused on it has been as an enabler and an equalizer. A lot of what I did and really used was focus on how technology can bring new opportunities to students and to equalize opportunities to students. So even as you look at our product Nettrekker and some of the things that I did when we rolled out the Nettrekker Differentiating Instruction version, we added a “Read Aloud” feature, again as an enabler, so that all students that are accessing the resources can be served and can gain benefit from the materials that were found in Nettrekker.

Selina: Your Nettrekker suite of products – it’s won over 20 awards, including the prestigious Codie awards for the best education solution in 2007. That must feel really good to be working on such an innovative and useful product. Can you tell us a bit about what differentiates your suite of search products?

Steve: Yeah, it actually is quite humbling to work with such a group that has such a great reputation and honor in so many different formats. Actually my first introduction to the company was when Nettrekker received two Codie awards at an event back in 2005. The reason that it differentiates is because it’s more than search. It’s really bringing the educational context to digital resource. By that, we’ve set out a complete K12 taxonomy.

So, regardless of what subject area you’re teaching, we have a taxonomy that defines the various aspects of, say for example in math and then geometry, and then the various aspects of geometry, we have a taxonomy that will build that out and each and every resource that we select, gets placed in that taxonomy. So as opposed to just being an individual resource hanging out there, we bring an educational context to it by placing it in that taxonomy. Then, as talked about earlier, we have the state academic standard which bring additional context to those resources.

Other ways that we differentiate are through the tools that we bring and the metadata that we wrap around the resources. So every resource has a variety of metadata elements that enables students and teachers to more intelligently search on the resources. So instead of just doing a key word search and finding a whole host of resources, we wrap metadata around it, which enables them to more accurately meet their particular needs.

Selina: Do you look for any specific engineering skills or mind set in your development or engineering teams?

Steve: I think the strongest thing that we look for is certainly strong engineering skills from a foundation within computer science. But more than anything we look for those who have an eye towards open solutions and integrations with open solutions as opposed to building a closed environment. We’re very much focused on those who have experience in working with integrations with a variety of open software, whether it is an open search tool or open integrations to templates on the front end in delivering the UI. The most effective way to deliver the resources in an open solution as opposed to a closed proprietary solution.

Listen to the full interview

Read the transcript

There is no perfect recipe for obtaining a fantastic product that users will love. However, when it comes to usability, some general guidelines and practices can be considered and followed. They are:

1. Know your end user and their working environment: Find out how the software you are developing will be used and get to know the end-user’s working environment. Look at the product from the end user’s perspective and use the existing product yourself to get a better idea. If possible, try to interact with the end user on certain functionalities to understand his/her expectations of the product.

2. Know the data that you are going to present to the user: Consider the volume of data, how the user is going to use the data (e.g. reports, graphs, etc.) while designing the user interface. This will impact the kind of controls you would choose to present the information and how the user would utilize the information.

3. Keep the UI simple: Show only useful and relevant information to the user. Do not clutter the screens with too many controls, buttons and other widgets. Think about how to present the information (data) in a powerful way to the user (e.g. grids, images, graphs etc.).

4. Navigation is important: Simpler the navigation – faster the task accomplishment. Provide clear entry and exit points for different functionalities. Ensure that the user can return to the appropriate location of the page from where the last action was taken. Make your navigation flexible to accommodate future requirements (e.g. tabs).

5. Be Consistent: Consistency in both appearance and behavior enables users to build an accurate mental model of the way the application works and accurate mental models lead to lower training and support costs. Use templates and a consistent approach while designing screens.

6. Create a match between your application and the real world: Always use words, phrases, and concepts that are familiar to the user. For example, say “Patient Chart” instead of “Patient Database Record”, show calendar icon for dates and so on.

7. Use standard GUI controls without altering their behavior: Users know how to use standard GUI controls. Do not change their behavior for your requirements. Avoid the usage of non-standard GUI controls, whenever possible. Position the controls for easy usage and group them properly.

8. Design for minimum inputs required from the user: Ensure that common inputs are required only once from the user. Do not ask the users to do more work for data entry, retrieval of information and operations. Spend more time on programming and minimize the user’s work (wherever possible, pre-populate the data).

9. Keep your user informed: Always let the user know what is happening in your application by providing appropriate feedback. When the user performs an action, provide feedback to indicate that the system has received the input and is operating on it. For example, if the user is deleting critical data, ask for confirmation before deleting the data. Make sure that the error messages use simple language, states the problem and provide solutions so that the user can fix the problem.

10. Expect that the user makes mistakes: Ensure that no matter what the user does,they can’t mess up. If they make a mistake, provide a mechanism to undo these mistakes and ensure that data is protected.

11. Consider technology impacts on UI design: Consider implementation techniques like Ajax, multiple image/content servers, personalization techniques to make the user experience pleasant.

12. Do time-study: User should be able to access important areas of the application with minimum amount of time and effort. Provide multiple paths to the user for all the important areas of the application. Do a time study on how the user would use your screens.

13. Do Hallway testing: Bring 2-3 people to play around your product and observe carefully, without commenting, while they are using it. Listen to their feedback – what they say and what they don’t.

 Building software is a complex effort – and when you need to be early-to-market with a quality product, it is even more challenging. Framework-driven development is an approach that attempts to increase developer productivity by making use of pre-built components and a solid underlying structure, which has already been tested.

 Frameworks help maintain developer discipline, limit unnecessary re-invention of the wheel and provide features that are almost universal requirements. Enterprise product frameworks go one step further by providing a pre-built product architecture layer with many cross-concerns and design decisions addressed. This helps development teams focus on solving business issues and reduces development time by more than 30%.

“Propel” is Aspire Systems’ enterprise product framework, that reduces the time and cost to develop a software product by about 30%. It comes with a pre-built, tested product architecture layer and can help developers focus on solving business issues, instead of worrying about basic design decisions and other cross-concerns.

Aspire Systems hosted a webinar on the importance of Enterprise Product Frameworks this month.

Some other key take-aways from this session:

• How product frameworks can be leveraged to your advantage.
• The quality and other indirect benefits of using frameworks.
• How Propel can reduce your development time and costs by 30%.
• Real-life experience of Ajuba Solutions on how they use Propel to develop their solutions rapidly.

The recorded webinar can be viewed by registering here

Many quality problems are a result of design and design adherence issues

1. Keep it simple: Simplify your design and do not complicate or over-engineer it. Frequently iterate through the design and look for avenues to improve.
2. Validate your assumptions: Design issues lead to major challenges in the product. So, if you have questions, get them clarified before you finalize the design.
3. Pay undivided attention to NFRs: Along with your functional requirements, design your product to fulfill non-functional requirements. Consider NFRs at the beginning of the design.
4. Use proven design patterns: Design patterns help in solving commonly encountered problems. Use design patterns wherever possible as it will help you uncover issues that can cause major problems during development.
5. Design interfaces first: This will help you start thinking about integration right at the beginning and will help in reducing integration challenges in future. This will also set the boundary for coding.
6. Build prototypes to validate your design: For every architectural and design step, build proof-of-concepts and prototypes to validate your design. This will help the design gain acceptance across the teams and also showcase how it works.
7. Communicate your design effectively: It is as important to communicate as it is to do proper design. Always use UML to depict your design; use a tool for depicting your design.
8. Go for reusable components and breakup the interface into logical pieces:  Reusable components help reduce development efforts and also increase the quality of the work – check with your architect though before picking up components. Choose components from reliable sources and make sure you comply with their licensing requirements (if any).
9. Incorporate statistics in your design: Numbers are very important. Bring in mechanisms to get performance statistics, usage statistics etc. into your design. This will help you a lot while analyzing the overall performance of the product.

Ask anyone who has heard of Agile what it means and the most likely answer you’ll hear is that it means making fast releases. This is quite an enticing view to managers who have spent far too long on projects that face delay after delay until they wonder whether it will be released at all. Unfortunately, this notion is wrong.

You see, Agile is not about speed.

As noted Agile speaker Venkat Subramaniam recently said, “if you do agile thinking it is all about speed, like a speeding motorist you will end up crashing and burning.”

If agile is not about speed, then what is it about? Agile is about making frequent releases in a sustainable manner. Anybody can make a fast release by foregoing all practices and quality. But how sustainable is that? What happens when you need to make the next release?

I recently had a project manager tell me that his team was already agile - they end up implementing everything that the customer requests, bypassing quality and discipline and working weekends to deliver. This is the opposite of agile - highly unsustainable, ad hoc coding.

One of the reasons why agile is hard to do is because it requires a lot of discipline to follow practices that enable development to be sustainable. Some of these are management focused like making frequent releases and collaborating with the customer, while others are technical like unit testing and refactoring.

To understand why technical practices are required, we need to understand a term called Technical Debt.

Technical Debt: Every time you take a shortcut, like writing code without a test or hack a solution without refactoring, you incur some technical debt. Just like financial debt, unless technical debt is repaid, it keeps adding on with interest. At one point, the technical debt becomes such a burden that you are spending more time just to prevent it from increasing further. At this point, your development has become unsustainable and your agile project is doomed to failure.

The purpose of the various practices is to maintain technical debt at zero or low levels.

With the background now set, we’ll examine various agile best practices in upcoming posts.

Most of the effort in the software business goes into the maintenance of code that already exists - Wietse Venema

1. Adhere to your design: Follow your architecture and High Level Design. For example, always write code with respect to the layering architecture mentioned in your design. Know where to write each piece of code. 

2.  Use reusable components: Wherever possible, design and implement reusable components. Also check for existing reusable components in your project and across other projects in your organization before developing a new one.

3. Prepare LLD before coding: Design the LLD for your piece of functionality/work in terms of standard UML based interaction or Sequence Diagram for validating the design. This will help you in bringing a thorough consideration of requirements for your design without expecting surprises at a later stage. This will also act as a validation gate before the implementation is started, capturing short comings (if any) in the design with respect to the requirements.

4. Don’t over-engineer your code: Follow a minimalist approach to meet business requirements; however, your software should be malleable enough to meet changes in requirements without major rework.

5. Adhere to coding conventions: Don’t introduce any new conventions of your own in the code, always adhere to the standards defined in the project. If you have any concern with the prevailing standards then raise a flag to the appropriate person before following your own standards. This will help in having maintainable code.

6. Attempt 0 compiler warnings: Always try to make sure that your piece of work compiles with 0 compiler warnings; no matter how existing/old code has been written.

7. Centralized database control: Make sure that a single person manages the database related changes e.g. table, field level changes, stored procedures etc.  Wherever possible make sure that you bring SQL into your source code repository.

As we continuously strive to become better product engineers at Aspire Systems, we have been identifying different sets of best practices for our technology teams to follow. While many of these practices may see quite generic, we believe that it sets the base – especially for new members in the team, and can be a useful checklist for the more experienced folks as well.

We’ve defined good engineering practices, coding and design practices, performance and usability engineering practices and testing best practices. We’ll post them up here one by one, starting with our take on good engineering practices.

Please feel free to let us know whether you agree or disagree with any of these – whether you think some of them aren’t really applicable in some cases – or if you have any additions/modifications to these lists. I look forward to hearing from you.

Our list of good Engineering Practices that will help you produce higher quality output:

1. Dig deep into requirements:  Collaborate frequently with all stakeholders and do more prototyping to clarify requirements. Use the Pareto rule: spend 20% of the effort required to identify 80% of the requirements, without getting into elaborate ceremonies. The remaining requirements will automatically fall in place once you start the iteration(s). Postpone doing any development work until you are clear with the concept (while everyone understands that you should expect changes).

2. Write structured code:  Think how you will structure your code before you start writing.  Write your code in small pieces – multiple functions and methods.  Extract common functionality into methods and never duplicate code.  Always look for reusing existing methods.

3. Use code analysis tools:  Make sure that you have a source code analysis tool such as FxCOP, PMD, etc. integrated with your IDE.  This will help you do code analysis easily and also help you adhere to coding standards.

4. Self review your work:  Make sure you review all your work products.  Never release deliverables without reviews.  Generate a report from your defect tracking tool and do a root cause analysis on the bugs you have introduced.  This will help you continually improve.

5. Write automated unit tests:  Always write automated unit test cases as a part of your work.  Integrate them as a part of your automated builds.

6. Test early and often:  Testing your work is your responsibility.  In addition to testing on your machine, always move your code to a fresh environment and test again.  Never release your deliverables without testing.

7. Document your code well:  Make sure you add inline comments in your code.  All functions and methods should be adequately commented.  Provide extensive commenting for complex logic.  Generate code documentation with tools like nDoc, javadoc and review it. 

8. Synchronize your code everyday:  Make sure you synchronize your code with the repository on a daily basis.  This will ensure that you have up-to-date source code from everyone and will reduce integration issues.

9. Communicate extensively:  Communicate every day with your team and manager on your progress and challenges.  Update your project management system on a daily basis (time sheet, project plan, task status, defect status, wiki, burn-down chart, etc.).

Despite the current gloomy economic climate, with IT budgets tightening and layoffs increasing, spending on software-as-a-service continues to grow in enterprise markets. Research from firms such as Gartner, IDC, and Softletter confirm this growth and predict that SaaS market expansion will continue despite the recession. Why is SaaS continuing to grow while many traditional licensed and on-premise software companies suffer from declining profits and static market share?

Join Aspire Systems for a timely Webinar on the 14th May, 2009 at 11:00 AM ET / 08:00 AM PT  featuring SaaS industry speakers Merrill R. (Rick) Chapman of Softletter and Richard Dym of OpSource discussing:

·        Softletter research analyzing increased SaaS adoption

·        Reasons/Factors influencing the SaaS wave

·        SaaS prospects/opportunities

·        The future of SaaS and SaaS companies

         Register Here for this Webinar