Traditional software engineering literature states that a software development project starts with a customer need which is 'translated' into a set of requirements. These requirements then are given to a 'development team'. After a period of time, this team will deliver a software system that will make the customer happy. And everyone lives happily ever after.
What is wrong with the above scenario? It tends to simplify and gloss over some critical issues.
1. Users are not always clear about the problem. This would mean that the information they provide is incomplete or comes as a personal view point.
For example, If H. Ford asked the general population what they really needed most in 1890 - the answer would have been "a comfortable horse carriage". As an answer this is quite valid, however the real issue is the definition of "comfortable". It could mean "less smell", "better suspension", "softer seats", "air conditioning" and the list would go on. One aspect is certain -- most will not be thinking in terms of "an internal combustion engine", "car radio", "DVD player" etc.. The reason is mainly lack of proper awareness of the latest advances in engineering (or the fact that a better technology is not available), along with the natural tendency of the human mind to think within a constrained framework which is determined by the training/education/emotional state. The key point here is the fact that they asked for a "horse carriage" -- the elimination of the horse was never in their minds.
Good software is built by teams that take input from the clients and integrate that with the current advances in technology to produce a solution that is 'different' and may often break the innovation barrier.
2. Translating the users 'real needs' requires an in-depth understanding of the 'users mental model', the constraints that they face in doing their work, the 'real goal', the core aspects that cause them the most pain. Unfortunately, to do this effectively you need to have the vocabulary that the user has. The development team must use and think with the vocabulary/language of the user. Once we start looking at the language, this invariably leads us into its closely associated ally -- 'the culture'. Language and Culture are very closely related, almost to the point where in practical terms they are inseparable.
Good software can only be build by a team that speaks the customers language and lives (or appreciates) the cultural context that the user lives in.
3. Software systems once built live in a certain infrastructure, here they tend to grow and are adapted over time, i.e. they evolve in an environment. The more components that a software system has to interact with, the more risk we need to watch out for. The sooner the information about this infrastructure and interactions is known, the better it is for the project. For example, could you build a house within out knowing something about the location? Will it be in a rain forest? In a city? On a noisy street? All of these aspects have a bearing on structure of the problem as well as the solution. As such, they determine the overall constraints that one must be aware of to solve the problem.
In a mathematical sense .. we have a problem which is like this - "Given X = 3, What is X*2?". If we did not know the value of X?, we cannot solve the problem. When building a software system -- there are a number of variables that need to have values associated with them before we have a chance of solving the problem. If the value of these variables is NOT know -- early phases of the development effort would have to be in ensuring that we do have answers for it.
Good software can only be build by a team that is aware of all the constraints that have to worth within. The earlier this information is provided, the lower the risk. Early phases of the software development effort should focus on minimizing (eliminating) these risks.
4. An interactive system cannot be properly specified in a static document. We can create static models with the time component (e.g. a Dynamic UML model). Unfortunately, most users are not trained in reading UML, just like most people would not be able to properly read an architects blue prints for a house. Further, these models are very limited because they do not incorporate or capture the 'actual/real' feedback that takes place between users and the software. It is possible to explain a game like 'Quake' with models and words? Does it really communicate to the users? How do we communicate "coolness factor"?
If we cannot properly communicate the intention of the development team, how can the client provide feedback that is of value? The only viable and practical approach is via prototypes that communicate the key aspects and ensure that the very interactions can be communicated. The downside of the prototype is that it often tends to limit the clients mind to the way the problem has been solved -- rather than put forward various options available. Given sufficient budget, we can build multiple prototypes each highlighting different interaction models. The risk is reduced, but it still exists and it is important that we acknowledge it.
Good software can only be build by a team that communicates the interaction models via a usable prototype. They would also be aware of the inherent limitation that the prototype lives in a temporary space and is not a true reflection of the correct/final solution.
5. Software is built to reduce or eliminate pain points (of the various users). There is a certain goal state which will remove the pain. In semi mathematical terms - "Given constraints X, Y and Z. Search and find a path that will remove/reduce pain point P". The path is the final solution. Very closely associated with this aspect is the fact that most users spent a large part of their time retrieving information, i.e. they use computer systems to find information rather than put information into the system. 80% of the interactions with a system would be to get information out, rather than put information in.
Further, the best way to move forward is by ensuring we have a good understanding of the various types of information that the users would want out of the system. If this is available, the actual inputs for the most part can be derived by inference.
Good software can only be build by a team that understands the global pattern of data input and output in the system. Is the system being built to capture information? Does it provide a bunch of reports? But, the critical issue is of course -- can the team trace every input and output back to a pain point?
Thursday, March 01, 2007
Sunday, February 11, 2007
Design is not just a set of features....
Recently, I had to go over yet another piece of software. As seems to be the general case, it was full of features. The development team was very proud of all the features that they managed to add into the product in the time frame allocated. The only problem is that a set of features is NOT design. Design is NOT class diagrams. Design is NOT a UML model of the interaction between a bunch of abstractions (classes, methods, modules, packages ....).
The problem is it is much easier to explain design by negation (what it is not) ... rather than say what it exactly is. If anything a well designed software system would consider aspects like: Interaction with users/systems, Flow, Entropy (Will this software system age well? Will it resist decay? Can it be maintained? Can we support it?), Can the user learn it incrementally? Are features even visible to the user?, Conceptual integrity, Domain Vocabulary and alignment with the domain etc...
To produce a reasonable design a number of aspects need to be considered before writing the first line of code, the more the better .. and yes, they need to be incrementally refined as we construct the system.
Sadly, we get to pick only two aspects from the ultimate list -- "Good, Cheap, Fast".
Leave a comment if you have you own set of non-designed software experience.....
The problem is it is much easier to explain design by negation (what it is not) ... rather than say what it exactly is. If anything a well designed software system would consider aspects like: Interaction with users/systems, Flow, Entropy (Will this software system age well? Will it resist decay? Can it be maintained? Can we support it?), Can the user learn it incrementally? Are features even visible to the user?, Conceptual integrity, Domain Vocabulary and alignment with the domain etc...
To produce a reasonable design a number of aspects need to be considered before writing the first line of code, the more the better .. and yes, they need to be incrementally refined as we construct the system.
Sadly, we get to pick only two aspects from the ultimate list -- "Good, Cheap, Fast".
Leave a comment if you have you own set of non-designed software experience.....
Sunday, January 21, 2007
Programming the web browser....
It had to happen ... so it did. A bunch of Usability researchers have put together a simple little Firefox addon called Chickenfoot that helps you program your web browser to complete simple tasks. Just in case you are going whaaaa? Here is a small example of what you can do in Chickenfoot and you will get the idea.
-----
go("google.com")
enter("Rajesh Vasa")
click("google search")
----
They provide a few more functions to help perform common tasks, and the language they created is an extension of Javascript.
Opera has recently announced on their blog, that they too have started to add similar functionality and should seep slowly into their stable releases. Firefox will most likely not make this a core functionality, since this is not really something most end-users will care for.
Now why is this great? What is the pain point that they are attempting to address?
To start with, this is real cool -- but will developers bother learning it and using it beyond 15-20 min? One area that I think it can help a lot is in making a certain category of testing scripts -- and there is no reason why this cannot be used in a rudimentary way for Test driven development for web applications. The other area that it can be used is for developing Firefox extensions (it has a button in the Development interface to deploy the code as an extension). The language and interface are simple enough to be used as an educational language to teach someone getting into programming (or) is keen to learn a bit more about programming.
It is always good to see incremental developments that have a potential to have an impact.
-----
go("google.com")
enter("Rajesh Vasa")
click("google search")
----
They provide a few more functions to help perform common tasks, and the language they created is an extension of Javascript.
Opera has recently announced on their blog, that they too have started to add similar functionality and should seep slowly into their stable releases. Firefox will most likely not make this a core functionality, since this is not really something most end-users will care for.
Now why is this great? What is the pain point that they are attempting to address?
To start with, this is real cool -- but will developers bother learning it and using it beyond 15-20 min? One area that I think it can help a lot is in making a certain category of testing scripts -- and there is no reason why this cannot be used in a rudimentary way for Test driven development for web applications. The other area that it can be used is for developing Firefox extensions (it has a button in the Development interface to deploy the code as an extension). The language and interface are simple enough to be used as an educational language to teach someone getting into programming (or) is keen to learn a bit more about programming.
It is always good to see incremental developments that have a potential to have an impact.
Wednesday, January 17, 2007
Problem Space Vs Solution Space
Software systems are generally built to satisfy a set of requirements. Unfortunately, typical requirement documentation states the intended solution rather than present the key problem. But, to build good software, the developers need access to the problem statement, ideally a set of pain points for each category of user. Why bother?? Because the developers are able to make better decisions.
A well stated pain point should be::
1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"
Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.
Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------
Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.
A well stated pain point should be::
1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"
Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.
Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------
Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.
Tuesday, January 16, 2007
On software developers...
In a recent interview, Bjarne Stroustrup (the man behind C+) said the following::
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and under-trained."
There are a few more gems like this in his interview, most certainly worth a read. Most experienced software developers would agree with much of the above statement. I however would add that computer languages should be designed to aid/improve productivity of a trained developer. This does not mean that they are easier.
One of the greatest improvements in productivity in a team development environment is the concept of a garbage collector. This is one aspect that C++ does not provide, and hence when using C++ for a solution it is best to have developers that are familiar with this limitation. Also, managers would need to understand that the benefits of C++ come with a very well known trade-off ... developers are just not as productive. When working in a team, it is important to know that the reference to an object/structure that you have been provided is safe as long as you use it -- developers being humans make mistakes and in a dead-line constrained environment you only need a few weak developers before it starts to get rather painful.
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and under-trained."
There are a few more gems like this in his interview, most certainly worth a read. Most experienced software developers would agree with much of the above statement. I however would add that computer languages should be designed to aid/improve productivity of a trained developer. This does not mean that they are easier.
One of the greatest improvements in productivity in a team development environment is the concept of a garbage collector. This is one aspect that C++ does not provide, and hence when using C++ for a solution it is best to have developers that are familiar with this limitation. Also, managers would need to understand that the benefits of C++ come with a very well known trade-off ... developers are just not as productive. When working in a team, it is important to know that the reference to an object/structure that you have been provided is safe as long as you use it -- developers being humans make mistakes and in a dead-line constrained environment you only need a few weak developers before it starts to get rather painful.
Wednesday, January 10, 2007
Apple iPhone & Apple TV - Initial thoughts...
I was very very curious like a lot of geeks about what the Phone would look like. So having seen the information presented from Apple, here are my initial thoughts...
- A touch-panel interface is quite risky, and will restrict the range of people that will buy this. The panel will get smudgy, I do not know how one can get around that. Until I use it, it will be hard to really understand or appreciate if it will actually work.
- It runs OSX .. an O/S designed to run a computer. I will have to assume that they will have re-worked quite a few bits to get it to fit into a phone. The real question is what they ended up sacrificing to get OSX to fit in a phone that small.
- 3 months after it is released, we will know if it will be a massive hit or not. But, I suspect that Apple will have to re-work and/or re-engineer many aspects of the phone over the next 6-12 months.
----
- Apple TV will be a hit (as predicted in my previous blog posting). The speed at which people will take it up may not be fast initially, but it will accelerate over time. The fact that you cannot record TV Shows on this device is a really interesting omission. I also think Apple will drop the price of this thing over time as they mass-produce.
Overall, very skeptical on the iPhone interface, I want to really use it before making a call on this one. Apple TV is very sleek and a lot of people will buy it.
- A touch-panel interface is quite risky, and will restrict the range of people that will buy this. The panel will get smudgy, I do not know how one can get around that. Until I use it, it will be hard to really understand or appreciate if it will actually work.
- It runs OSX .. an O/S designed to run a computer. I will have to assume that they will have re-worked quite a few bits to get it to fit into a phone. The real question is what they ended up sacrificing to get OSX to fit in a phone that small.
- 3 months after it is released, we will know if it will be a massive hit or not. But, I suspect that Apple will have to re-work and/or re-engineer many aspects of the phone over the next 6-12 months.
----
- Apple TV will be a hit (as predicted in my previous blog posting). The speed at which people will take it up may not be fast initially, but it will accelerate over time. The fact that you cannot record TV Shows on this device is a really interesting omission. I also think Apple will drop the price of this thing over time as they mass-produce.
Overall, very skeptical on the iPhone interface, I want to really use it before making a call on this one. Apple TV is very sleek and a lot of people will buy it.
Saturday, January 06, 2007
Predictions for 2007 (and beyond?)
Never done a prediction list before (officially), but I want to archive my predictions in order to review them at the end of the year and see how close I get.
-----
1. The earth will get warmer than before, yup - we are heating up. There will be even more evidence that humans play a big hand, and there will be many who will doubt/deny/question it. London will have another 40c day.
For some scientific and serious discussion - http://www.realclimate.org
2. The drought will finally break (Melbourne, Australia) between Feb - Jun'07.
3. Oil price will continue to climb. It will be > US$75 by Dec'07.
And now for some technology stuff::
4. Windows Vista will slowly start to seep into the developed world. Developers using the .NET framework will the first lot to move over, the rest will very slowly move over the next 3-5 years. Windows will continue to have security issues.
5. Linux will start to gain a lot more traction, with increased usage coming from South America and Asia. Device manufacturers will start to adopt it in greater numbers.
6. Apple will release a product line to start taking over the living rooms and are very likely to actually succeed. Most likely a Mac TV with the ability to save TV shows, go online and play simple games. It will be easy to use and very likely going to be a huge hit. They will grow their slice of the computer market.
7. The new Microsoft Office will most likely not gain much adoption this year (or the next for that matter).
8. 2007 will be the year that web applications extend their reach. Google will release a plug-in (or some technical module) that will allow GMail and their Word processing/Spreadsheet applications to work offline. This will start off a new revolution -- and a lot of clones will start off.
- Image processing applications will start to go web based (Maybe not to the quality and richness of photoshop, but they will hit the 80-20 rule without much effort this year).
- There will be attempts made at creating a completely online IDE. If you can have a word processor online, why not an IDE. This will be year the web application development will start to shift gears. Once the IDE shifts to a server, the whole deployment game will change as well. [The question is, will Google, Yahoo or Amazon release an IDE that will allow you to build applications to run in their infrastructure -- I hope so, it will be one of the biggest changes to the way we buil software in a long while]
- Assembling web applications using web-components will start to get a bit easier.
9. Offshoring and Outsourcing will turn around and the local development fad starts.
10. Custom software development starts to slow down for most business applications. It is now all about crafting a solution using existing technologies/components quickly. Integration, customization and selective enhancement will be the new buzz words.
** Personally, I hope #8 is spot-on and #3 is totally wrong.
-- Rajesh
-----
1. The earth will get warmer than before, yup - we are heating up. There will be even more evidence that humans play a big hand, and there will be many who will doubt/deny/question it. London will have another 40c day.
For some scientific and serious discussion - http://www.realclimate.org
2. The drought will finally break (Melbourne, Australia) between Feb - Jun'07.
3. Oil price will continue to climb. It will be > US$75 by Dec'07.
And now for some technology stuff::
4. Windows Vista will slowly start to seep into the developed world. Developers using the .NET framework will the first lot to move over, the rest will very slowly move over the next 3-5 years. Windows will continue to have security issues.
5. Linux will start to gain a lot more traction, with increased usage coming from South America and Asia. Device manufacturers will start to adopt it in greater numbers.
6. Apple will release a product line to start taking over the living rooms and are very likely to actually succeed. Most likely a Mac TV with the ability to save TV shows, go online and play simple games. It will be easy to use and very likely going to be a huge hit. They will grow their slice of the computer market.
7. The new Microsoft Office will most likely not gain much adoption this year (or the next for that matter).
8. 2007 will be the year that web applications extend their reach. Google will release a plug-in (or some technical module) that will allow GMail and their Word processing/Spreadsheet applications to work offline. This will start off a new revolution -- and a lot of clones will start off.
- Image processing applications will start to go web based (Maybe not to the quality and richness of photoshop, but they will hit the 80-20 rule without much effort this year).
- There will be attempts made at creating a completely online IDE. If you can have a word processor online, why not an IDE. This will be year the web application development will start to shift gears. Once the IDE shifts to a server, the whole deployment game will change as well. [The question is, will Google, Yahoo or Amazon release an IDE that will allow you to build applications to run in their infrastructure -- I hope so, it will be one of the biggest changes to the way we buil software in a long while]
- Assembling web applications using web-components will start to get a bit easier.
9. Offshoring and Outsourcing will turn around and the local development fad starts.
10. Custom software development starts to slow down for most business applications. It is now all about crafting a solution using existing technologies/components quickly. Integration, customization and selective enhancement will be the new buzz words.
** Personally, I hope #8 is spot-on and #3 is totally wrong.
-- Rajesh
Subscribe to:
Posts (Atom)