Application software development

This is what I consider important when doing software development:

1. An application is (often) inherently limited by the technology used to develop the application. So before starting the development of an application, try to assess how flexible the application should be (in the future). Or better, try to anticipate on interfacing, and try to avoid (future) vendor or technology lockin. If interfacing of a technology is a potential future problem -- an example for Java based applications could be the complexity of having to deal with JNI -- then choose another technology. If you have enough money and human resources, interfacing is never a problem.
   
2. A brandnew application is best developed in an organic way. So not first design, then implement, that only works for applications we already know how to implement, and those applications can often be written in one day (so it is a configuration, not an application). An example of a 'configuration' is relational databasing, using Microsoft Studio, the development of such 'applications' is fully automated. If your true application needs good support for workflows, good support for customizability, talk to your (potential) users on a regular basis. Maintaining the appropriate data layering when an application grows, is one of the most important aspects of organic growth. So sometimes, organic style development means splitting one software component into several software components, as indicated by the nature of the data (don't mixin recordsets with workflow configuration data). OTOH, sometimes appropriate data layering is not possible, because there are no efficient data conversion algorithms to do the job (a couple of times I had to develop algorithms to do such conversions -- tricky job). In either case, organically grown applications must always be complemented by good tests, see below.
   
3. An application must be tested on user visible functionality (not: atomic unit tests, I have seen that go wrong quite often). Functional testing and integration testing have several aspects to the inner, like guarding consistency, but also to the outer, like defining workflows and as a guide for user documentation writers. So tests should be self-documenting for the documentation writers. The way I implement this last feature is by using a single set of test specifications, to run the tests, and to convert them to HTML.

I think of these three points as the most important things to keep in mind when developing a (brandnew) software application. I did not talk about backward compatibility, installation, deployment and roll-out. Then, there is obviously also sales and marketing.