Wednesday, 25 August 2010
Protect Shred Throw away
Wednesday, 21 July 2010
Development environment
Sunday, 6 June 2010
Elevate thinking on Software Development Models.
a) Someone is talking about a new model.
b) The benefits list is longer than your shopping list.
c) There are also convincing Wow! Wow! examples.
d) It is some thing very different from all the models you have ever seen, heard or used.
especially that mean Waterfall model.
Then, the all time champion false claim
e) The model is promised to deliver you success at all times !!.
Here is what I think.
1) The Waterfall model gave us the basic stages of software development. That's the truth. Face it. It is NOT a guaranteed to fail. It might fail.
2) Every Software model has all the stages laid out by the waterfall model. Rarely do you see a new phase in the new models.
3) It is how you string these phases together, how much effort you spend in these stages, that makes the difference and the different models.
The questions to answer before adopting a new model.
1) What is the process you are following now?
2) What precisely is wrong with that process?
- Look for answers in Cost, Effort, Schedule.
- Get the numbers straight for the above three.
3) How much is the new process profitable in the above three?
4) Is this worth the shift?
5) Above all, Is your business process, team process compatible with the new model??
i.e can you map it to your processes?
These basic questions can set things really straight.
Monday, 17 August 2009
Windows Server 2008
http://h0bbel.p0ggel.org/windows-server-2008-as-desktop-laptop-os
Tuesday, 7 July 2009
ShopEasy v1.1
Friday, 24 April 2009
To prototype or not to prototype
All engineering disciplines frequently use scaled down models to prove a concept before actually building something real or the real thing. This is the case, be it related to building architecture, bridges or aircraft manufacturing. So what about software? As an answer comes up the word, prototyping. The question is whether to or not to prototype? The question deserves special attention in software domain. This is due to the following reasons. First, software is created by developers who are unfortunately not the end-users of the product. Second, the end-user is not usually involved in specifying what they want, be it to see, type in or interact. In addition to that, the so called requirements get passed through quite a lot of hands and is perused and interpreted by the lot too. The funny thing is that, each will have an idea of what needs to be done, let alone how and with what. When this comes to the developer again there will be an interpretation of what is to be done. Finally, what the user wants is in his/her head and cannot be elicited in one go or so. The end result of this can be an unhappy user who thinks the software is useless or an irritated client who thinks the real objective was not met. For the developer this result can manifest as anything from, burning down new screens the user wants, dealing with the so called ‘changes’ to re-doing the whole thing.
- If your team has thought of a concept which is core to building the solution. Prototyping can help in proving this concept. If the prototype proves your concept wrong, then you are in a position to plan accordingly rather than having to re-trace in the middle of development. It can also uncover any mistakes in your concept.
- You might have designed the solution with application layers and so on. Prototyping would be helpful in making sure things will get along as they were planned in the first place. If things do get along, you have something to look at when you build the real thing, a distinct advantage.
- It can help in comparing technologies that can be utilized to deliver a solution.
- You can identify bottle necks earlier which otherwise unnoticed will surface as impediments. i.e you make things as risk free as possible at an early stage.
- Above all, the user/client when presented with the prototype will start talking more than you expected. You will get a clear idea of ‘what they want to see’ and how they want to interact with the solution. I.e your interface will be change-proof as much as possible. There will be a better understanding between the two.
In short, prototyping does help a software development team to move in the right direction based on facts and deliver what the user wants in the first go itself. i.e if you have not been able to deliver the right product in the first pass, you should think about prototyping.