When working as an application developer [and probably in any other profession as well], a healthy question to ponder is the following: Is this the best way to do this task/process, or is there a better way?
Do you find yourself or others doing repetitive tasks? The solution – automate if possible. Do you find that users of the system you develop for are often doing repetitive tasks? If there’s time and a cost-benefit/prioritization analysis proves it is worth doing – automate! Combine tasks. Simplify things. The key: Paying attention to what you and others are doing and questioning whether there’s a better way.
Here are two examples:
- MyBPS [www.mybps.org] is the current web application used by the Boston Public Schools for managing student information [registering students for schools, giving grades, assigning transportation, etc]. It was built in ASP.NET 1.1 and has a tab-based structure [users have access to tabs based on what roles and teams they're in].
One of the administrative tasks developers sometimes need to do is add a new tab. Unfortunately, given the way the site is designed, it is a multistep process. You have to:
- Log in and go to the Admin tab.
- Scroll down to a link to add a module definition, and then on the next page set the source code file and a name.
- Click the ‘Add module’ link to create a …
....
- You’re done!
The steps could fill up a whole page in a book. There has to be a better way…
And there is. Automate it! I fired up SQL Profiler and went through all the steps manually, grabbed the SQL from the profiler and encapsulated it into a Stored Procedure used to create a new tab. It has two parameters – the source code file location and the tab name. 8-10 minutes of administrative work done in the blink of an eye.
- We sometimes get a report of a bug on the MyBPS system. We’ll usually find out what tab the error was reported on and some additional information to help us track down the issue. Unfortunately, we don’t always get a stack trace or enough information to pinpoint what source code file is at fault. This can lead to poking around the ASP.NET solution or doing global source code searches for small phrases [which return dozens of pages which need to be reviewed one by one]. There has to be a better way…
And there is. All the data about how the source code links to a tab [via a module definition and a module] is stored in the database tables. I wrote a Stored Procedure that takes a tab name [or partial tab name] as a parameter and outputs all source code files linked to that tab name. To come full circle, I also wrote the opposite procedure – one that takes a source code file and outputs the associated tab. With these two Stored Procedures, tracking down bugs has never been easier.
