Consulting

5 Tips on using Rapid Application Development (RAD)

Welcome Back! I hope you enjoy the content on this site. If you have not done so already, you may want to subscribe to my RSS feed or become a fan of this blog on Facebook. Thanks for visiting!

As consultants which I believe most of the reader of this blog are, or even if you are a developer working for a software company, time is always of the essence. We are always trying to do more in less time either because we have a tight deadline or to free time to do other things we enjoy.

A concept that is not new is RAD or (Rapid Application Development) promises to let us do just that.

In fact so many software companies have tried many approaches to tackle this problem but unfortunately as it has been said before,  there is no Silver Bullet to beat the monster. There is no one size fits all methodology that can help all ISVs.

What I have seen over the years is that software vendors come up with tools that are either too hard to learn and thus us developers have to climb a pretty steep learning curve just to try them out and see if they are viable for our work environment. I am thinking here of the (Rational Rose Suite, The DSL tools by Microsoft) and so many others. Or on the other hand, they come up with too simple and weak solutions that are OK for small scale applications but that quickly bite the dust when facing large enterprise requirements. The slap on a dataset for each query comes to mind. You can try that with a multimillion records table and see how quickly it crashes!

When we started our company our first client was a large insurance company that needed a web application used by insurance brokers to sell their  products. We had a very tight deadline, and we needed a solid and scalable application that can handle multiple  transactions per second.

Today the system is not just a web application to sell insurance  products, but a full blown insurance system that handles claims, manages billing and also integrates with the company’s accounting system.

Last year we shipped version 3.0 of the online system and haven’t had a bug report since then. So how did we do it?

1. Write a framework

Even with the tight deadline we knew we had to write a solid code base that we can reuse for other projects and also to give us the flexibility to add new modules to the application without too much fuss.

The framework includes:

• Logging interface
• Data access helpers to handle transactions, factory to instantiate you DAL services,
• Exception handling and logging
• UI base objects and custom controls.

The framework should be optimized for performance and scalability. It has to be fully unit tested. You can think of it as the heart of your application, if it stops beating ..well  your application is dead.

2. Use Code Generation Tools

Back when I was in university I had written data access code generation templates for Code Smith. That’s years before LINQ or the Entity Framework. I just couldn’t bring myself to using DataSets and DataTables when I saw the performance hit when compared to DataReaders and Custom Objects.

Without code generation every time you make a change to your database you have to rewrite the Database access code, mapped objects, services, and UI. Retest everything and hope it works.

With the generated code we only need to change the services and the UI so that’s your work cut in half already.

3. Don’t reinvent the wheel for each project

Yeah I know that new tool or framework is so cool that you have to use it in  your next project. But your customer only sees 3 things in your software:

• Does it work?
• Does it address the business requirements?
• Did you ship on time?

Which framework, or technology you used is the last thing he/she will care about. So stick to what you know. I am not saying you can’t learn new techniques or explore new frameworks, but do that on side projects and don’t use it in your projects until you can answer this questions with confidence: What are the chances I blow this project if I use (insert your new framework here). And your answer is none because I used it on X, Y and Z projects and I master it.

You should also have a viable business argument why you would want to switch to this new framework. Either because it’s going to cut our development time in half, or it offers a better user experience for the client etc…

4. Simple is Always Better

Remember your main goal is to ship a working version of your software while including the most feature you can on time. This doesn’t go along so well with trying to come up with the most clever solution. For example If your application needs to get a CSV file from a webservice and parse it to include those records in the database. You can write that in a few hours. You don’t have to put a BizTalk server to orchestrate all that for you.  you get my drift? Most of the time the simplest solution is the most elegant one and the safest.

5. Modularity

I try to always  break our applications in small modules. Why?

• We can reuse those components in different project
• As customer requirements change we have very loosely coupled modules that we can just replace without having to refactor all the code.
• Give ownership of each module to a team member and thus speed development time.
• It’s easier to unit test each module.

I am sure I left a few things out so do share your ideas in the comments please.

Looking for a great book on .Net? Pro C# 2010 and the .NET 4.0 Platform, Fifth Edition

Hope this helps,

Hatim

5 Tips to get the most out of your coding time

I remember seeing an add from Microsoft I believe for hiring programmers and the jist of it was “We give you an office with a door”.

Why you might wonder?

Well, it might take up to 20 minutes to refocus on the task at hand after you get distracted either by a phone call, by a coworker barging in or by a video someone posted on Facebook.

I will give you an example of a spiral I used to find myself in. I will be happily hacking at this new feature that we need to ship soon and an email notification shows up for an email that I was cc’ed in so I open the email read it and can’t remember what it  was about so I end up reading the whole thread just to remember. Then I switch to my browser to see if there is anything new in my RSS reader, oh wonder if someone sent me something on Facebook. Off to Facebook I go.

An hour later I am back to visual studio and completely lost the thread to what I was doing. And that’s when bad stuff happens, bugs introduced and things get forgotten.

These are a few tips I use now to keep me focused and get the most out of my work hours.

1. Close your internet browser

As hard as it might seem, learn to open your browser only if you need it to research something related to the task you are doing.

What I like to do is to dedicate a couple hours before I start  coding to research the references I need. So that when I get started it’s only coding and nothing else.

Try it for a week and see how much stuff you get done.

2. Close your mail client / instant messenger

Don’t worry, if something really urgent happens you would know about it. You don’t need to keep your mail client open at all times, and read each email as it arrives.

Think of how many emails you are CC’ed in just for the sake of it and to which you have no say in. And think of how  many hours you waste opening those emails and getting distracted by them and having to refocus on what you were doing before.

Set specific times at which you read your emails. I find just before my lunch break and at the end of the day the best time. I find emails a good way to unwind :). I also end up writing better quality emails instead of the quickly I have to get back to what I was doing mess I used to send to clients.

If you don’t want to close just turn off the notification sounds and status bar alerts.

3. Unhook your phone  (or put it in silent mode)

This follows on the no email theory. I ask all our clients that if something is really urgent to send me an SMS. They almost never do so I let the calls go to voice mail  and I can check it later.

This tip is also good for keeping your clients  happy and show your professionalism,  you wonder how? Well when they leave a voice mail your already know what they want to talk about when you call them back. Say the leave the following message:

Hey Hatim, I wanted to know what’s the status of feature N° 156 and if we are still on for the system update schedule by the end of the week.

What you can do is go find out what the status of that feature, check with your team that everything is good and ready to go for the system update.

The phone conversation will take less time as you won’t have to stall them and scramble while you open your tracking application or IM the person responsible for the feature or your team to see what’s going on.

4. Buy good noise canceling headphones

I have a pair of Bose® QuietComfort® 3 Acoustic Noise Cancelling® Headphones. These are great for listening to music and also shields you from all the distractions. Coworkers talking in the hallway, the guy talking loud on his phone, … . They also work I just put them on without anything playing.

A nice plus is that they have great sound quality!

Of course you don’t have to use noise canceling heaphones they are just nice to have, regular headphones will do too, specially with some loud music!!

5. Make small and regular breaks

When I am coding I like to have a 5 to 10 minutes break each hour and a half to 2 hours. I either go get a coffee,  talk to a coworker, check voice mail, walk in the hallway. The idea is when I get away from my  screen I can have a better spatial thinking and find new ideas or solutions more easily.

It’s also revigorating and gives you a mental boost when you are working.

Oh I can finish this new screen and have my break.

A great book on how to manage time is Tim Ferris’s “The 4 Hour Work Week” you can get it for free as an audio book if you sign up for a free audible trial or if you prefer you can get the dead tree version.

I hope this was helpful and would to would love to hear if you have any tricks and stratagems to keep your self focused.

Hatim

8 Must Have Tools when Going to the Client’s Site

Have you ever been to a client’s site and you are in the middle of a large deployment and something goes wrong. Of course not! yeah ..sure Don’t you wish then you had packed with you the source code code, X or Y tool to help you better diagnose the issue and save you from either a trip back to the office to debug the issue or having to delay the release a couple of days.

I had a few of those and so now I have my Swiss Army Knife of tools that I always have with me just in case.

1. My “Deployment Laptop”

I have an entire development environment setup on a laptop that I use when I go home or when I am at the client’s site.it has IIS, VS 2008 with TFS, SQL Server, SQL Reporting Services and SQL Integration Services.

2. SysInternals tools

I can’t remember the last time I used these, but they did save my butt so many times trying to debug some weird behaviors. You can get them here.

3. The latest version of the source code

We normally have the releases all packaged but Just before I go or the night before I would do a get latest from TFS to my laptop.

4. A backup of the development databases

I have a SQL Script that would create a backup of our development databases that I always take with me. Even though during our development cycle we always have patch scripts for all the changes we do - which works fine most of the time – sometimes things don’t go as smoothly as planned so being able to load a dev database and do a quick compare can be a life saver.

5. RSScripter

We use SQL Server Reporting Services for several clients and they create new reports and modify existing ones and of course they don’t know who has the latest version. RSScripter let’s me download the .rdl files from the server that I can then modify and redeploy to the server.

6. A Custom Diag tool

I wrote a custom Diagnosis tool that checks the connection to the database server, authorization stores, AD etc….Great for quickly detecting minor issues. (Network cable damaged, DNS issues, user rights…)

7. A Copy of the Clients app.config and Web.config files

I always keep a different copy for deployment. I got burned so many time by forgetting to change a config setting.

8. Oh…An extra sweater in case you are going in the servers room

Not really a tool but useful if you don’t wanna wake up with a sore throat the next day.

What else would you add to this list? Please leave your thoughts in the comments.

Hope this helps!

Hatim