Eureka!

Over the past few months I have been working on creating an optimum development environment for creating web applications in .NET. The current development environment is for creating web applications in PHP.

While the tools differ (.NET vs. PHP), the goal is still the same: creating web applications. Thus, you should be able to use the same development environment. Now, this will not hold water if you have a PHP environment that is highly specialized toward PHP development; the same goes for strongly .NET dependent environment set-ups.

My contention here is that your development environment should be set up according to the goal, and not the specific flavor of technology being implemented. This will allow for migration between different technologies without creating a huge upset in the way things are done. “What are you specifically getting at here?”, you ask me. Well, lets examine what a development environment entails.

Research
Ideas don’t just make themselves. A lot of thought, trial and error, and playing around goes into perfecting an idea and developing a use case and proof of concept. This includes database designs, code, integration of 3rd-party-tools, plug-ins, and so forth.

Documentation
Once your idea matures and you are able to show proof of concept and derive a use case from your research, it needs to be documented. Often documentation is a burden placed on developers or technical writers to satisfy process, and not necessity. I’m not talking about writing a doctorate on the work that needs to be implemented (code changes, functionality updates, new project design, application design, etc.). What I’m talking about here is the short and sweet documentation that is concise, demonstrative, and clear on how to implement the proposed items outlined in the document. You should be able to hand one portion of the documentation to any developer who should be able to create the desired end product without having to consult with the client. It needs to be that good! And at the same time you should be able to hand the other part of the documentation to the client, so as to give them a clear picture of exactly what the end product will do, what its specific parts are, how they interact, and how the client’s users will interact with them. Yes, it has to be that good. Only then will you achieve a useful product that your clients will be happy with.

Architecture
You will architect your products and applications based on the documentation, as well as your findings from your research. Architecting and documenting a web application design often go hand-in-hand and will require extensive revisioning of the documentation. Your application architecture needs to implement best practice designs wherever possible. If there aren’t any for your given situation, don’t hesitate to create best practices and publish them! Public scrutiny is your best advocate in creating high quality designs.

Development
The development stage of the product should not entail any unforeseen activities. Yes, you have developers, but they should not be trying to figure out problems as they are developing your applications. All problems, hurdles, and glitches should have been thought through in the documentation and architecture phases. At this point the development should follow the guidelines of the documentation, just as a cook follows a recipe.

Testing
While your situation may not allow for test-driven development, it is the best way to achieve your development goals with a minimum of bugs, and it also encourages use of best practices. Test-driven development means that you first develop a test class with various test methods that test each functionality of your application. Since you have thoroughly documented all functionality, you already know what you want to achieve; you write your test methods to test for the desired result by running the methods, classes, or functions of code in your application that correspond to that functionality. If the function fulfills those requirements without failing, you have achieved your goal, and your test is successful; if not, your test fails.
Like I said, not all environments will allow for this, and in the event you can’t or decide not to implement this, you always need to test your code during its development to ensure that you are meeting your goals. This testing should optimally include peers, so as to expose your code to their scrutiny. They will have feedback, certainly if there are errors, and more often than not even if your code runs fine. There is always room for improvement, and it is a great way to advance your programming skills.

Trial Phases
Once portions of the application are preview-ready they should be tried by the client. Never abandon your client during development. Keep them up-to-date at least on a semi-weekly basis, if not daily. Your client will never ever get the design specs exactly how they need to be in practice, so the trial of functionality will reveal any problems that actual implementation may hold. Keep your client in lock-step with your development, show them what’s going on, and even what is not working. Give them the opportunity to adjust the project. This is not necessarily scope creep, but more often corrective measures. We like to label this scope creep so that we can blame the client for missed deadlines. However, not all changes need too be implemented right away. Document any planned changes and add them as enhancements after the project is rolled out, or in another phase of development. Try to avoid adjusting your current documentation to much, as it will cause disruption in the development process, if many developers are working on many different parts, and have to rework a lot of their code. On the other hand, if extensive re-work is required it may be best to halt all development and iron out the details with the client, re-document, and then go from there.

Deployment
Once all trials have been performed satisfactory, the product needs to be deployed into the production environment. The deployment mechanism should have no impact on the development environment, and should not be part of, or depend on, your development environment. If at all possible, deployment should be automated, so as to avoid human error.

Maintenance
We all know that there will be updates and bug-fixes down the road, no matter how good we code an application. Maintaining bugs, and tracking errors should be done in a standardized way, regardless of technology. This means that your applications should inform you that the client is having problems. You should be aware, and maybe already have a patch available when the client comes to you with their issues.

Everything I outlined here is technology independent. It is a collection of procedures that can be adhered to regardless of the technologies being used. This means that you should be able to switch from PHP to .NET development in the same environment with no impact on your procedures, making the life of your management so much easier. Heck, it will make your life so much easier, too.

Now, this isn’t as easy as it sounds. We often have special tools to aid us with each of the above processes, like bug-tracking, project management, deployment, code versioning, and so on. Often these tools integrate with our development environments to make our lives (at the moment) easier.

This is the actual crux of my post: what tools can aid you with your processes, while remaining technology independent. I will post more on this as I work through it myself.