I have been teaching a crossover developer for about 8 months now, we’ll say. We both started to give up our Saturday mornings and come in to work on projects the company would not allocate time for. An example would be the “Automated Build Tool,” as we call it. Basically, it has all the functions you need to build and release the product to stage or production, along with doing backups and running sql scripts. Not rocket science really; products exist for it, but since this is stage and production, we wrote it in-house. I personally have Cruise Control running on my development server to keep a running build of the current production tag and the current trunk. I inherited this build machine from a developer who left the company.
When we first started, we talked about design patterns and methodologies. When asked what I prefer, I said,”RAD.” RAD, or Rapid Application Development, is really the precursor to this current Agile craze that I tend to dislike. RAD was thought up by some IBM guys and put into a book in 1991. If you want to learn more about the book version of RAD, see Wikipedia.
For the most part, the “RAD” I use stays true to the book version.
My Version of RAD:
- Meet with the end-user or client to talk about what problem they are trying to solve and what needs to be addressed by the project.
- Lock yourself in a room of software engineers whom you get along with very well. If you can’t all agree to watch or to order food from , you should scrap the idea of using RAD.
- Ignore all code guidelines and pick a function and start writing it. Plan to use test cases to make sure all functions pass a valid test case. Example: validating a user login to a system should cover a yes, no, and what did you enter?
- Make the newest guy design a user interface (or send him to get food from and do it yourself).
- Make sure to take a shower and go back and meet with the end-user again. Make them use the software. Do not demo it at all and say, “Hey, this does that.” You want to see them fail and every time they do, note this, as you will need to fix it.
- From your first prototype, you should have a lot of questions for the end-user. These will be questions like, “Have you thought about Single Sign On instead of just a login field?”
- Now that you have shown the end-user, you know about their company/product/job by asking such amazing questions, and you need to get feedback. These will be questions like, “Did you notice anything that was missing,” or “Is there a feature you might not have thought about in the first session?”
- Back to the software engineer pen. Once again, stocked with Redbull and Doritos. You will create a new project. The code you showed the client is now the documentation of what needs to be in this version.
- During this code phase, you will start to use “code guidelines.” You will remember OOP means reusable code. Clean up that horrible nested foreach loop I know you are still amazed at the fact that it worked.
- Now that the code has been re-factored into a new project with the list of changes from the client in mind, you are ready to meet with the client again.
- This time, shower is optional, as you should not have been working 24/7 like last time. I am assuming you shower regularly. If not, now is a time to start.
- Just like the last meeting. This time, the end-user should know this will be the final revision to the spec. Besides, not much should be changed from here except the UI.
- Now, you get to go out and get dinner with the team at a nicer .
- When you are back to the office, open a new project and, this time, you will follow the coding guidelines to the letter. You will remember that design patterns work. You will XML comment this bad boy. You will have code so simple your mom could add a new feature!
- The product is shipped to QA and a technical document writer. This cycle should be sort and sweet. I mean, you wrote the product 3 times; I hope you learned a lot from the first 2. Your code should be secure, stable and elegant to read. When looking at the code, you should weep—as this is the stuff they write books about.
- Drop off the end product, collect that well-deserved check, and now you will use the waterfall method. If the user wants a change, you will document the change request in the normal boring fashion. These should only be minor tweaks, anything else, and you will need to remind them that the new request was way out of the scope of the initial project, and they will need to start a new project if they want those changes.
The truth is, I find this method to be the greatest way to get beautiful code. You and the end-users both contribute to the same problem: the 500 “what ifs” that come along with writing software. Agile tries to handle this with iterations when the “what if” is small. This does not handle a complete redesign like, “We need to change from XXXX back-end to XXXX third-party.” You can argue that all that needs to be done is switch out a class, if they did use OOP. Sadly, this is often never done.
Most companies that hire me have a software system that is living on a life support machine. One wrong config key, and it’s all over for the software. Okay, so I make it seem more hellish than it is, but—really— most software I touch, design and standards still are not a thought.
During our 4 hours on Saturdays, I watched Youtube and Netflix while the crossover developer would sit there and struggle to get anything to work. Every now and then, I would say, “You know it would be a lot faster to use this?” or “Why reinvent the wheel? That feature is built into the framework.” I rattled off classes and functions with the parameters needed to make the function work. He would, of course, ask if all developers knew this, and I would say, “No. My background is debugging and software architecture. I have been paid to know the framework in and out. Most developers understand that something must exist but will need to look up a help document.” When the project was done, they congratulated us. He has the habit of always giving me credit when I feel no credit is due. I was no more helpful than Google with good word suggestion.
The first version was to get the software working and tested. This, of course, went to production to make sure it did work, with a careful eye over it all. The second re-factor started when our boss asked for SVN tags to be sorted by name. Instead, I offered to just filter the results based on a string entered into a textbox. While I was in the code, I started to rename all the badly named buttons and lists. For instance, button1_click became btnBuild_click. He got the idea and spent a few days re-factoring the code and splitting it out. Now that the code was in SVN, and I had full access, I started the final re-factor of moving all logic code to a single class. This way, only display logic would remain in the front end. This would allow for the majority of the code to be ported to a Windows service. You would then just need to add the queue logic and be done with it. After reviewing the code changes with him, he said, “Now, I see why you support RAD.”
Writing software once with a frozen, well-defined specification beforehand is like building a Skyscraper with the first draft of blueprints. While the end-product might work, it was not designed for the pool on the 5th floor and will require a major overhaul to support the weight. It would have been better to make a few drafts and get feedback during each draft.