Archive for April, 2008

Public Speaking

My current workplace holds fortnightly lunchtime discussion sessions on topics of software development. At these sessions, a speaker will talk about a particular software development topic in front of up to 100 people, ranging from project managers and business analysts, to designers and developers. These sessions are a great way to facilitate learning across the organisation. Anyone who has something valuable to say can volunteer hold one of these sessions. However, the prospect can be a little daunting for those who have some great ideas, but are not accustomed to speaking in front of such a large group.

I recently read an excellent book called Practices of an Agile Developer, which mentions spreading knowledge in a team using “brown-bag sessions”. Each week, a member of the team leads a lunchtime (hence the “brown-bag”) discussion on a topic that’s of interest to the team. Not only is this a great way to spread knowledge in the team, but it also allows individuals to gain confidence at speaking in front of others. It is much less daunting than speaking in front of a large audience of strangers, as these people are peers, who can give feedback and reciprocate discussion. Once you gain confidence at speaking, you can look at holding a talk at a local user group, or give a presentation in front of a larger audience.

Public speaking is something that most people have to do at some stage in their life. For developers it can mean giving a presentation, leading a technical discussion, or simply having the guts to ask a question at a conference. Starting out with small discussions in front of a small group of peers would be a great way to practice your articulation and gain confidence at public speaking.

The Importance of Using “Real” Test Data

During development, data is usually required to effectively test an application. The test data used during development often doesn’t reflect the real data that will be used in production. I recently worked on a large web-based application that was developed using test data that developers wrote. This data was quite meaningless (often comical) and there was just enough of it to fill the layout. At the time this seemed fine, after all, it’s only test data, right? So what happened when we eventually migrated the thousands of records of real data? Lo and behold, things no longer fitted on the page and performance became a real issue. This caused a delay to fix the problems before we went live. Lesson learned:

Use test data that accurately reflects production data in both content and quantity.

Ok, so when should real data be introduced into the system? Before writing any code would be ideal! That doesn’t mean get all the data up-front, just enough to demonstrate each feature as it’s developed. In good agile fashion, a test data suite should be developed incrementally along with the application. When anyone (developer, tester, customer, user, etc) is testing out a new feature, they should be seeing how it functions with production-standard data.

So, where do we obtain real data? From the people who know best – the customers. They may be able to provide you with some data they already have in a database or spreadsheet. If not, then send them a spreadsheet containing the required columns and kindly ask them to populate it with real-world data.

Maintain a test data script

Automate the creation of test data using a database script. Keep this script up to date with schema changes and wipe-down the test data often to ensure it is kept up to date.

Use paging and filtering

When displaying a list of data it is important to think about how much of the data will be displayed at one time. If there is potential for a large amount of data to be displayed, then use paging or filtering to ensure that the page can handle large sets of data. If you don’t implement paging, it is safest to cap the number of records that can be displayed. This ensures the application will continue to function with large sets of data.

Real data improves the understanding of a system

By developing an application using real test-data, both customers and developers gain a better understanding of how the system will be used. Customers are able to see how their information is handled and displayed by the system. Developers can see what kind of information the customer will be entering and ensure the design suits the customer’s needs.

Identify problems early

Real test-data allows us to identify potential performance issues and display problems early. It can also help to identify and correct serious flaws in functionality early in the development cycle.