Wonder how many times you heard this as an answer to a specific question by an expert of the matter. Scratched your head about what it means and question their authority. Yes?And it is true in many respects too given the choices we have around our technologies. That is a good thing, right? Well, guess what... it depends...
Recently I have been tasked with creating a technical specification document for a given application module. I delivered the document knowing what I know at the time and tried to avoid Big Design Up Front (BDUF) anti-pattern. I have to admit there are quite a few holes in my document but my goal is to fill up them as I find more about the requirements and increase my understanding of the application. So far we have is a few screens of wire-frames, an initial functional specification document. The business analysts are hard at work in peeling those requirements and creating/modifying the functional specifications. It's all good in the end as long as we have a grasp on the amount of the documentation. And, yes, we are using an agile methodology and have daily scrum meetings and two week Sprints. We are staying focused.
Including myself, the team is very new to this company. What are some of the challenges? Well, lack of requirements one might say, but I am yet to be on a project where this isn't the case. The second that you think you nailed down the requirements, guess what happens. It changes! Head First Object Oriented Analysis and Design book had a good chapter for this, “You're perfect. Now change!” Exactly. So I am not too hung on this. Just get me enough to start coding...
There is some worry about the business process, and lack of decisions. We are also going to use an off-shore team as well to do some of the development and testing. I expect to be working closely with this team at some level. I have a few questions and concerns with that, but I will bring it as it moves forward. Keeping development cycles short, feed-back loops tight and close. Wire-frame developers griped a little about not seeing the whole picture, but sometimes you don't need to.
As far as technologies go, I am all about .NET development which is our platform. This is a web-based application with multiple tiers, heavy emphasis on separation of concerns, testable, decoupled layers. There will be WCF services used by the business tier as well as third parties. I am pushing ahead with ASP.NET MVC framework with business objects (logic) in the middle, and ADO.NET Entity Framework in the data access layer. We are going to use Test Driven Development, writing our tests first, thinking “unit testing”. I realize that TDD is not unit-testing, but I am already spreading the words/ideas about the functionalities to test. I really believe this will help us increasing our code-coverage numbers as well as CCHIT requirements fulfilled. My goal is when some one asks me how this works, I could just run a few unit/integration tests and show that they meet the requirements. Yes, got to have tests... there is no other way around that!
Meantime I plan to write quite a few throw-away proof of concept code to aid the actual coding. I plan to address the cross-cutting concerns, exception management, authorization, authentication, logging, caching (defer it until I have more hands on with application), encryption and security.
Our database is SQL Server with some interfaces to legacy DB2 databases, We do have an aggressive time-line, as with most development teams. We are definitely going to be busy. Well, if you are going to ask me how is it going? You will know my answer...
Happy Coding!
