What do we at IT people really do? Do we solve problems? or Do we build solutions?
Put it another way - 'Should we provide IT people problem statements (or) ask them to build a specific software?"
What would be ideal to provide as input into an IT project?
* Customers are unhappy with support provided (Pain point)
---
* Build me a website that will allow customers to search a Knowledge base (Constrained -- pseudo solved requirement)
So, now the question is do we state the pain point or just the requirement? What will yield a better piece of software?
Well, its getting late here at I write this blog entry -- so let me get to the point. ..
A lot of software is often built so specific requirements, which often yodel on and on by providing a lot of detail about the requiremed functionality. Sometimes we get lucky and the Quality criterion is also provided. There are models galore to go with all this stuff too. I only wish that they clearly state in simple words things like "Current customer pain points are...". Is this information really needed? Ofcouse it is -- because a clear problem statement goes a long way to help the developers check that they are building a product that will get used, i.e. it solves the core problem.
For many years, I have used a simple technique to help me before starting off software development projects. Take a requirement spec. and classify the information provided inside taht into two chunks -- "Problem space" and "Solution space". If there is nothing stated about the 'problem space', the project will most likely fail or stay in the dazed state. Why? Most likely it will not be built because it has no purpose, even if it is built, then the customer will either not accept it (or) worse still, say lovely words about the software and then ignore it.
The bottom line ... Do you want software that works? or Do you want a lot of software?
Wednesday, June 28, 2006
Sunday, June 25, 2006
Will Ruby on Rails take off big time??
The Ruby on Rails bandwagon is moving at quite a pace. Looking around on the blogosphere, it almost looks like it will replace Java and .NET for web application development. Now, is this likely? Will it really happen? Well ... here is my take on it.
Background: Rails is a web-app development framework that is about 15 months young now. So, as frameworks go, it is a baby. The interesting bit is the momentum that it has gained in such a short timespan is amazing. Given, the fact that it is competing with a large number of frameworks that have been around for quite a bit longer. Not to mention that this has no 'commercial' marketing machine supporting it. Shows what a dedicated few people can achieve.
So, will it replace ASP.NET, JSP, J2EE? Short answer -- unlikely. Why? Universities are not teaching Ruby + Rails yet, and they do not seem to be in a hurry to start replacing their Java/C/C++/VB programming streams in any hurry.
Of-course, some of you may contend with an argument like "professionals will learn Rails if it will save them time", "IT people will invest a few weeks of their time learning new things because it is cool". Ofcourse, both arguments assume (incorrectly) that full-time professionals will be able to dedicate 2-5 weeks full-time learning a new framework, and then attempt to build something with it. This is the big problem with something totally new, radically different. Java worked because it built on top of C like syntax which is already used widely, so it cuts the resistance curve. The other thing with professional developers is their skills are incremental, i.e. they have picked up bits and pieces of new things over a period of 3-5 years. This eventually makes them quite good even with a monster like J2EE. Learning Rails means we need to invest a large pool of time in a short burst, and this is quite hard for full-time professional developers.
Rails is well thought out -- and it will take time to learn. Ruby will take time to learn -- developers need assigned free-time to be comfortable with its API, the IDE's, the tools and its bugs/workarounds. And, we need books like "Rails for Java developers".
Then there is the chiken-egg problem, for a framework to take off big time, we need a large pool of people that know how to use that framework. People will invest time if something is already popular (or) looks likely to take off.
After having played with it a bit, I really hope that something like Rails becomes available for Java/C# soon (with the same power). It certainly makes developing web applications easy, and I'm starting to appreciate the power behind the idea 'convention over configuration' -- which is really what underpins the UNIX way.
Background: Rails is a web-app development framework that is about 15 months young now. So, as frameworks go, it is a baby. The interesting bit is the momentum that it has gained in such a short timespan is amazing. Given, the fact that it is competing with a large number of frameworks that have been around for quite a bit longer. Not to mention that this has no 'commercial' marketing machine supporting it. Shows what a dedicated few people can achieve.
So, will it replace ASP.NET, JSP, J2EE? Short answer -- unlikely. Why? Universities are not teaching Ruby + Rails yet, and they do not seem to be in a hurry to start replacing their Java/C/C++/VB programming streams in any hurry.
Of-course, some of you may contend with an argument like "professionals will learn Rails if it will save them time", "IT people will invest a few weeks of their time learning new things because it is cool". Ofcourse, both arguments assume (incorrectly) that full-time professionals will be able to dedicate 2-5 weeks full-time learning a new framework, and then attempt to build something with it. This is the big problem with something totally new, radically different. Java worked because it built on top of C like syntax which is already used widely, so it cuts the resistance curve. The other thing with professional developers is their skills are incremental, i.e. they have picked up bits and pieces of new things over a period of 3-5 years. This eventually makes them quite good even with a monster like J2EE. Learning Rails means we need to invest a large pool of time in a short burst, and this is quite hard for full-time professional developers.
Rails is well thought out -- and it will take time to learn. Ruby will take time to learn -- developers need assigned free-time to be comfortable with its API, the IDE's, the tools and its bugs/workarounds. And, we need books like "Rails for Java developers".
Then there is the chiken-egg problem, for a framework to take off big time, we need a large pool of people that know how to use that framework. People will invest time if something is already popular (or) looks likely to take off.
After having played with it a bit, I really hope that something like Rails becomes available for Java/C# soon (with the same power). It certainly makes developing web applications easy, and I'm starting to appreciate the power behind the idea 'convention over configuration' -- which is really what underpins the UNIX way.
Subscribe to:
Posts (Atom)