I’ve been very busy of late, focusing on prototyping little things (along with some personal things). This is the first time I’ve had a real level of control of how a greenfield application will be built. In the past I’ve experienced too many obstacles to achieve a desirable outcome.
But now a twist of fate along with; a bit of planning, brainstorming and prototyping is on track as a “greenfield” application.
I can’t go into the details of the application and it’s operation, so I thought I’d share a little summary list of things we’ve considered, discussed, and even decided* upon for our application.
*Decided as far as we haven’t changed our mind yet.
1. This is by no means a complete checklist – but if you’ve got the opportunity to be part of creating a new application which has some degree of flexibility in terms of deadline pressure and implementation. When I say flexibility I mean ability to make choices without intense time pressure or a lot of other external pressures. I hope we’ll discover if the time we’re taking was viable based on our final delivery time frame and delivery outcome.
2. This is biased towards patterns and technology common in the Microsoft.NET space.
Once there are some more interesting prototypes/concepts, I’ll post some lessons learnt or just cool solutions (if we do end up producing something “cool”).
So onto the list.
How long you spend on:
- A pure research phase.
- Brainstorming sessions with stakeholders / domain experts.
- General discussions amongst developers
- Lock down some big decisions, only to change course if it’s an impedance.
- Restrict new ideas from even more stake holders, (people with opinions).
How to conduct the:
- System architecture.
- Presentation platform; web, desktop, mobile.
- Presentation framework; ASP.NET MVC, WPF, Silverlight.
- Development patterns; MVC, MVP, MVVM.
- IoC container.
- Mocking and Unit-Testing frameworks.
- ORM frameworks.
- Database approach in general
- Using a non-tradition database technology along the lines of NoSQL.
- Initial features you need to deliver, before you have a beta.
- Newish techniques to adopt/use. (New to developer community or just your team).
- Beta technologies to take a bet on.
but most importantly, how you will deliver:
- Business/customer value.
- A pleasant end user experience.
- Support and help.
- Confidence in the system.
Obviously several of the above choice branches are reasonably trivial, and come down to personal preference and familiarity, clear cut example is the choice of a unit testing framework.
As a summary point for our choices, the current set of “locked down” technology choices revolve around: