Been catching up with a few old contacts over the many X-Mas lunches, a common theme seems to be how often I hear the words ... "if only the management understood software development", or "why would they appoint a team lead that has never programmed to lead developers?" and the classic .. "they hired 5 developers to create system X, and they are still arguing what X is!" (i.e. they hired well compensated contractors to surf the web).
This phenomenon seems to be quite common in large organizations whose primary business is not software (as in banks, retail..). I guess the senior management in these businesses does not really understand software or the people that tend to build software well.
In other words .. would you appoint a head chef that does not know how to cook? A bank would not do well in the cooking business, so why should they be good at software development.
In all fairness, most large non-IT organizations do tend to outsource their entire IT work to larger IT specialists (with nifty 3 letter acronyms). But, you still need to set the direction and control the army that you just hired.
Wednesday, December 27, 2006
Sunday, September 17, 2006
A few simple thoughts...
- Artists create to express (Emotion)
- Designers communicate
- Engineers solve problems
- Scientists define boundaries and explore (Abstraction/Exploration)
Effective IT people combine all of the above seamlessly. This entry was inspired by a graphic posted by John Maeda.
Sunday, August 13, 2006
Architecture is.....
What indeed is architecture? Martin Fowler summarises some views on architecture in his article - "Who needs an architect?", one of the most interesting definitions from that article is 'architecture is the set of decisions that the team hopes to get right, because they are expensive otherwise'.
For a number of years (some of which included me having a title "Solution architect"), I never really thought much about what architecture is, why we need it and if we are in need of an architect role. The worst part is that I thought less about architecture being a 'Solution architect'.
I like the idea of thinking about architecture as a set of decisions, but it is probably simpler to stick to the IEEE definition that 'architecture captures the structure (static/dynamic) and organisation of a system'. This is the one that most people intuitively think of as architecture -- lots of lines, bubbles and squares on paper, i.e. structural models. It is one of those things that are cheaper to accept and move on, i.e. the fight/effort does not yield a win-win situation.
The interesting thing however, is that an architecture does indeed reflect the set of decisions that someone has taken. We have a 'Start menu' in Windows because there was a decision taken by someone, or a group. In essense, every software system is nothing but a reflection of the set of decisions that people have taken.
Now for the crux, the real issue is "Which decisions do we bother to communicate?", and how much effort to we invest in this effort? And by starting to ask these questions -- we may start to reflect on our decisions rather than focus purely on the end-result.
Another blog soon on a technique for getting started with architectures ....
For a number of years (some of which included me having a title "Solution architect"), I never really thought much about what architecture is, why we need it and if we are in need of an architect role. The worst part is that I thought less about architecture being a 'Solution architect'.
I like the idea of thinking about architecture as a set of decisions, but it is probably simpler to stick to the IEEE definition that 'architecture captures the structure (static/dynamic) and organisation of a system'. This is the one that most people intuitively think of as architecture -- lots of lines, bubbles and squares on paper, i.e. structural models. It is one of those things that are cheaper to accept and move on, i.e. the fight/effort does not yield a win-win situation.
The interesting thing however, is that an architecture does indeed reflect the set of decisions that someone has taken. We have a 'Start menu' in Windows because there was a decision taken by someone, or a group. In essense, every software system is nothing but a reflection of the set of decisions that people have taken.
Now for the crux, the real issue is "Which decisions do we bother to communicate?", and how much effort to we invest in this effort? And by starting to ask these questions -- we may start to reflect on our decisions rather than focus purely on the end-result.
Another blog soon on a technique for getting started with architectures ....
Sunday, August 06, 2006
Laws of software systems...
Over the past few months I have been writing notes of software development. The following are "laws" that I've condensed from these notes which are a reflection of my current appreciation of software. Some of these laws are based on observation, some are from data I'm analysing as part of my research into software evolution.
So here are the "laws"....
1. If you *notice* a software system, it is probably broken.
-- We do not really notice a DVD player, the interface to a car or another other device that we use day-to-day. They just work, do their thing and stay out of the users' active mind. This observation is a generalisation from that view point. A more direct metaphor is - "we only notice a garbage-bin that is full".
2. Software has both 'form' and 'function'.
All systems have 'form' and 'function'. It took me a number of years to actively start seeing this distinction. End-users, need not -- but as software developers, we need to be aware of what a software system is -- distinct from what it does to help a user.
3. Every function in a system should reduce (remove?) pain, or increase pleasure. Functions that cannot be tied back to a pain-point of a pleasure-point are redundant.
This one is rather obvious -- but I wanted to state it to make sure that we actively acknowledge it. Before a team plans and allocates resources -- this is probably the one law that should be used as a sanity check before executing the plan.
4. Software systems can only be constructed to help users achieve *definable* goals.
If we cannot state the 'goal' or the end result just cannot build the software. The problem unfortunately is not as simple as this law makes it seem, but a more detailed blog is probably warranted later to explain my views on this one.
5. The form, the function and structure of every software system reveals the *culture* that built it. Evolution of a software system is limited/enhanced by this culture.
The way a system is constructed and managed says a lot about the culture that built it. We may marvel at the pyramids (and to a certain extent the sky line of a city like New York) -- both of which do reflect the attributes of a culture that built it. It may not say much about the motivation, but it certainly does show what a culture considers valuable and worthwhile. In the software world -- Programming languages, Operating Systems and even simple text-editors say a lot about the culture that produced them. Culture almost always indicates a set of beliefs, and a guiding philosophy. The evolution of a product, will reveal quite a bit about this philosophy -- what do they fight for, what do they abandon and when do they acknowledge their mistakes?
6. Evolution is a sign of life, activity and usage. Systems that do not evolve are either perfect (or) irrelevant.
This one has already been stated (in a different way) in Lehmans' Laws of Software Evolution. I want to acknowledge it and add to my set of laws.
7. A holistic appreciation of problem and solution complexity is far more important than any process.
This is probably to a certain extent contradicting Descartes reductionism approach. But, a software system does show a number of emergent properties -- especially once we take into consideration that the system includes the 'users'. Many complex systems end up being used in rather odd ways, features are combined in never before imagined ways -- this is essentially what I now consider to be 'humanistic', the final outcome is not predictable -- it is however bounded. Processes do not build systems, it is the people that do. A process may help capture the current set of values (beliefs, philosophy), but that is about where they stop.
8. History suggests that the solutions that 'last' are those that are 'efficient'.
Efficiency is a beast that works on a number of different levels, but here I would like to take a simplistic argument and suggest that 'efficient' systems are those that use the least amount of 'energy' to achieve a user-goal. Energy includes everything from time taken to build the system, the CPU cycles it takes to get the job done (i.e. electricity used) and ofcourse the time it took for the user to learn it, *remember it* and use it. All of these are very closely inter-related (see Law 9)
9. Scalability is one attribute that can be predicted based on the complexity of a software system.
Software that takes a long time to build and/or learn will never reache a 'large' user base, limiting its scalability. These systems tend to be rather inefficient. The best systems are those that are flexible enough to allow the users to extend - allowing new properties to emerge.
10. Limitations in software are limitations of the collective human mind.
Software systems are built by teams (a collective human mind). If something does not work as expected, chances are it has been over-engineered to perform a specific task and/or takes a long time to learn (with respect to the goal). Ideally, systems that seem to engage us humans are those that are simple to learn, but require a lot of time and effort to master.
There is a few more to add to this list, I'll post them once I have finished adding detail to them. I will try to elaborate more on each law in some depth in later posts. Do feel free to comment, contradict, or lend further support to them. These 'laws' will evolve as I change and understand better, so these are not Universal statements -- just "Vasa's laws of software systems...."
So here are the "laws"....
1. If you *notice* a software system, it is probably broken.
-- We do not really notice a DVD player, the interface to a car or another other device that we use day-to-day. They just work, do their thing and stay out of the users' active mind. This observation is a generalisation from that view point. A more direct metaphor is - "we only notice a garbage-bin that is full".
2. Software has both 'form' and 'function'.
All systems have 'form' and 'function'. It took me a number of years to actively start seeing this distinction. End-users, need not -- but as software developers, we need to be aware of what a software system is -- distinct from what it does to help a user.
3. Every function in a system should reduce (remove?) pain, or increase pleasure. Functions that cannot be tied back to a pain-point of a pleasure-point are redundant.
This one is rather obvious -- but I wanted to state it to make sure that we actively acknowledge it. Before a team plans and allocates resources -- this is probably the one law that should be used as a sanity check before executing the plan.
4. Software systems can only be constructed to help users achieve *definable* goals.
If we cannot state the 'goal' or the end result just cannot build the software. The problem unfortunately is not as simple as this law makes it seem, but a more detailed blog is probably warranted later to explain my views on this one.
5. The form, the function and structure of every software system reveals the *culture* that built it. Evolution of a software system is limited/enhanced by this culture.
The way a system is constructed and managed says a lot about the culture that built it. We may marvel at the pyramids (and to a certain extent the sky line of a city like New York) -- both of which do reflect the attributes of a culture that built it. It may not say much about the motivation, but it certainly does show what a culture considers valuable and worthwhile. In the software world -- Programming languages, Operating Systems and even simple text-editors say a lot about the culture that produced them. Culture almost always indicates a set of beliefs, and a guiding philosophy. The evolution of a product, will reveal quite a bit about this philosophy -- what do they fight for, what do they abandon and when do they acknowledge their mistakes?
6. Evolution is a sign of life, activity and usage. Systems that do not evolve are either perfect (or) irrelevant.
This one has already been stated (in a different way) in Lehmans' Laws of Software Evolution. I want to acknowledge it and add to my set of laws.
7. A holistic appreciation of problem and solution complexity is far more important than any process.
This is probably to a certain extent contradicting Descartes reductionism approach. But, a software system does show a number of emergent properties -- especially once we take into consideration that the system includes the 'users'. Many complex systems end up being used in rather odd ways, features are combined in never before imagined ways -- this is essentially what I now consider to be 'humanistic', the final outcome is not predictable -- it is however bounded. Processes do not build systems, it is the people that do. A process may help capture the current set of values (beliefs, philosophy), but that is about where they stop.
8. History suggests that the solutions that 'last' are those that are 'efficient'.
Efficiency is a beast that works on a number of different levels, but here I would like to take a simplistic argument and suggest that 'efficient' systems are those that use the least amount of 'energy' to achieve a user-goal. Energy includes everything from time taken to build the system, the CPU cycles it takes to get the job done (i.e. electricity used) and ofcourse the time it took for the user to learn it, *remember it* and use it. All of these are very closely inter-related (see Law 9)
9. Scalability is one attribute that can be predicted based on the complexity of a software system.
Software that takes a long time to build and/or learn will never reache a 'large' user base, limiting its scalability. These systems tend to be rather inefficient. The best systems are those that are flexible enough to allow the users to extend - allowing new properties to emerge.
10. Limitations in software are limitations of the collective human mind.
Software systems are built by teams (a collective human mind). If something does not work as expected, chances are it has been over-engineered to perform a specific task and/or takes a long time to learn (with respect to the goal). Ideally, systems that seem to engage us humans are those that are simple to learn, but require a lot of time and effort to master.
There is a few more to add to this list, I'll post them once I have finished adding detail to them. I will try to elaborate more on each law in some depth in later posts. Do feel free to comment, contradict, or lend further support to them. These 'laws' will evolve as I change and understand better, so these are not Universal statements -- just "Vasa's laws of software systems...."
Wednesday, August 02, 2006
Functional programming...
I just read a blog entry at Joel on Software regarding functional programming. It is a nice and simple explanation of what can be done when we can properly abstract functions.
Joel then goes on to say some silly things like Google is great because of the power of functional abstraction which may be taking things a bit too far, but he does make a very valid point about the elegance that can be gained when a programming language treats functions as first-class-citizens.
There is also a previous blog entry where Joel provides a long rant about how Universities are turning into "Java training centers", this one is quite valid and does show how much we do not show current generation IT students when we teach them programming.
We have corrected a number of these mistakes in the Professional Software Development course at Swinburne (just to be open about it, I was on the team that designed this course). We have an entire subject that deals with different programming paradigms as well as subjects that educate students in software construction, we most certainly do not want to 'train' students to build software poorly (that too in Java)....
Joel then goes on to say some silly things like Google is great because of the power of functional abstraction which may be taking things a bit too far, but he does make a very valid point about the elegance that can be gained when a programming language treats functions as first-class-citizens.
There is also a previous blog entry where Joel provides a long rant about how Universities are turning into "Java training centers", this one is quite valid and does show how much we do not show current generation IT students when we teach them programming.
We have corrected a number of these mistakes in the Professional Software Development course at Swinburne (just to be open about it, I was on the team that designed this course). We have an entire subject that deals with different programming paradigms as well as subjects that educate students in software construction, we most certainly do not want to 'train' students to build software poorly (that too in Java)....
Wednesday, June 28, 2006
Problem solving or solution building?
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?
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?
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.
Friday, June 23, 2006
Predictions for operating systems...
I've completely removed all traces of Vista for now. Well on my rather slow machine was not exactly running that fast under Vista (AMD 3200, 1Gb RAM, 128Mb GeForce). I guess when the base operating system needs about 400-500Mb of RAM just for itself, it leaves very little for other apps. It does slow down once you have a few apps running at the same time ... [iTunes, Eclipse, Tomcat, Firefox, Office, PDF Viewer]. The weird part is that the same set of apps. all co-exist quite happily on XP, and under Ubuntu you almost forget how many apps. you really are running.
As a whole, Vista does have a nicer UI compared to XP, Explorer took a while getting used to. IE7 is actually usable (the only weird bit was having to endure ads. on the internet -- Firefox+Adblock ensures a practically ad-free browsing experience). I'll certainly give it a go once they are out of Beta and into the final releases. Assuming I do not have to upgrade my hardware to get the Vista experience.
After having fiddled with it for a few weeks, most sys. admin. types will need to spend quite a few months getting into this O/S. Given the number of changes and issues that are likely to crop up, the uptake in the corporate (managed) environment will be very slow. My guess is that it will get a solid uptake around 2008 by which time most of the hardware companies would have caught up, SP1 will be out, training material/books will be available. So, if you work in a corporate environments where they love SOEs (Standard operating environments), then be very patient .. this is not a roll-out that they will be willing to undertake very fast. Bottom-line: Vista does not offer a lot of new features that are 'needed', then again it has the best looking Solitaire I've ever played -- so you never know... they may just have the killer app. to convince most management.
----------
Here is my predictions for the O/S land:
1. Vista will be released in Dec/Jan timeframe to the world, with SP1 in around middle of 2007. (Yes, I'm probably in the 0.00000001% of the population that belives that M$ can pull this off)
2. Linux will gain popularity slowly and probably will get about 10-15% of the O/S market over the next 3-4 years. I'd love for Linux to be 20-30%, but sadly Windows is what most people know and like -- that kinda builds up a massive resistance to change. The one strong upside for Linux is the fact that the $100 PC project is using Linux and a lot of device makers are using Linux in their product lines. If you count these into the picture.....
3. OSX will continue to gain market share as well. They may be able to get upto 10% or so as well over the next few years. My confidence is not that high for this one though.
4. Vista will be about 30% of the O/S market in the next 3 year timespan. So this will really mean that in 2009/10 .. XP will most likely still be the dominant O/S. Sad, but that is the most likely outcome. Ultimately, this means that the funky new technologies that Microsoft has built into Vista will not take off very fast.
For good or bad, the future looks very fragmented indeed.
As a whole, Vista does have a nicer UI compared to XP, Explorer took a while getting used to. IE7 is actually usable (the only weird bit was having to endure ads. on the internet -- Firefox+Adblock ensures a practically ad-free browsing experience). I'll certainly give it a go once they are out of Beta and into the final releases. Assuming I do not have to upgrade my hardware to get the Vista experience.
After having fiddled with it for a few weeks, most sys. admin. types will need to spend quite a few months getting into this O/S. Given the number of changes and issues that are likely to crop up, the uptake in the corporate (managed) environment will be very slow. My guess is that it will get a solid uptake around 2008 by which time most of the hardware companies would have caught up, SP1 will be out, training material/books will be available. So, if you work in a corporate environments where they love SOEs (Standard operating environments), then be very patient .. this is not a roll-out that they will be willing to undertake very fast. Bottom-line: Vista does not offer a lot of new features that are 'needed', then again it has the best looking Solitaire I've ever played -- so you never know... they may just have the killer app. to convince most management.
----------
Here is my predictions for the O/S land:
1. Vista will be released in Dec/Jan timeframe to the world, with SP1 in around middle of 2007. (Yes, I'm probably in the 0.00000001% of the population that belives that M$ can pull this off)
2. Linux will gain popularity slowly and probably will get about 10-15% of the O/S market over the next 3-4 years. I'd love for Linux to be 20-30%, but sadly Windows is what most people know and like -- that kinda builds up a massive resistance to change. The one strong upside for Linux is the fact that the $100 PC project is using Linux and a lot of device makers are using Linux in their product lines. If you count these into the picture.....
3. OSX will continue to gain market share as well. They may be able to get upto 10% or so as well over the next few years. My confidence is not that high for this one though.
4. Vista will be about 30% of the O/S market in the next 3 year timespan. So this will really mean that in 2009/10 .. XP will most likely still be the dominant O/S. Sad, but that is the most likely outcome. Ultimately, this means that the funky new technologies that Microsoft has built into Vista will not take off very fast.
For good or bad, the future looks very fragmented indeed.
Thursday, June 22, 2006
Microsoft decoded...
So what does Microsoft (M$ from now on .. or should it be M$$ .. M$^$?) do? I am (was) fairly certain that it is an O/S company that also makes a nice Office suite. Then again, maybe they are a Music company .... scratch that -- I mean they are an Internet portal, nah .. they are a search company.
Just off the top of my head M$^$ are into .. an O/S, Office suite, E-Mail, Internet search, Mobile phone software, iPod killers (yup that one has been announced), Firefox killers (IE8?), PS2 killers, Gameboy killers (I'm sure that is next), Input devices, Web cams and that list keeps getting longer and weirder each day. Add to this the fact that they also want to compete with (or kill off) Oracle, SAP, IBM, Google.....
The rationalists/analysts will offer silly (logical) explanations like "M$$ has forgotten what it is that they do". Baa-humm-bug, my 'conspiracy theoritical explanation' is that they are not really a software company at all ... M$ is in fact a large charity focused on helping out C/C++ programmers.
huh? Well, think about it ... they employ about 60,000 developers. They lose money on just about product-line except Office and Windows. Given that about 10,000 developers are working on these two product-lines. They effectively are looking after 50K C/C++ developers. There you go ... this is the truthiness behind the world of Microsoft.
-- Rajesh
Just off the top of my head M$^$ are into .. an O/S, Office suite, E-Mail, Internet search, Mobile phone software, iPod killers (yup that one has been announced), Firefox killers (IE8?), PS2 killers, Gameboy killers (I'm sure that is next), Input devices, Web cams and that list keeps getting longer and weirder each day. Add to this the fact that they also want to compete with (or kill off) Oracle, SAP, IBM, Google.....
The rationalists/analysts will offer silly (logical) explanations like "M$$ has forgotten what it is that they do". Baa-humm-bug, my 'conspiracy theoritical explanation' is that they are not really a software company at all ... M$ is in fact a large charity focused on helping out C/C++ programmers.
huh? Well, think about it ... they employ about 60,000 developers. They lose money on just about product-line except Office and Windows. Given that about 10,000 developers are working on these two product-lines. They effectively are looking after 50K C/C++ developers. There you go ... this is the truthiness behind the world of Microsoft.
-- Rajesh
Monday, June 05, 2006
Office 2007, Office 12 ...
Still not sure what M$ will decide to call the final version - 12 or 2007. Either way here is my initial thoughts after using it now for a few days.
The basic Office apps come in a 450Mb install file. Install is fairly quick and as things go fairly straight forward --- esp. since I installed everything.
I've played around with Word/Excel and Powerpoint mainly. I belive there is something deeply wrong with an email app. that needs 100Mb, so Outlook never got a serious look.
All of the apps. have been given a bit of a makeup, with a new UI. To start off, my first 20min. with the UI has not been very enjoyable. After using it for a few days, I must say that the Usability people working at M$ have been doing a great job. The UI is very very responsive (even for a Beta), and the ribbon thing actually does work.
The downside is the first few hours of getting used to the changes are not very plesant (to put it mildly), but once you get over that short term pain -- things start to look up. I like the work esp. in Powerpoint. Working with Tables and Pictures is now very easy - esp. giving the images nice effects that just make it look it that much nicer.
Word-2007 is unfortunately a bit of a memory hog now [beta?], still after persisting with the new interface - I'm starting to see the whole point behind the changes. There are a lot of tasks that are now a bit more accessible (actually you now know they are available).
Excel has a number of minor tweaks to its Usability. Charts and scrolling are much much better now. The Excel charts can be given that 'pro' look without too much effort :)
Bottom line: If you plan on moving to Office 2007, invest a few hours into the new UI and it will slowly start to grow on you.
Business case: This is a much harder .... I just cannot see enough new features in the product that will make businesses move to the new product line. The UI will most certainly require users to undertake some level of training, the hardest bit to get over is the complete lack of a menu-bar. Habits are hard to change, my feeling is that the final version will most likely have the menu-bar put back in just to make users feel a bit more at home. A lot of companies are still using Office-10, some have moved to Office-11 fewer still will move to Office 12.
-- Rajesh
The basic Office apps come in a 450Mb install file. Install is fairly quick and as things go fairly straight forward --- esp. since I installed everything.
I've played around with Word/Excel and Powerpoint mainly. I belive there is something deeply wrong with an email app. that needs 100Mb, so Outlook never got a serious look.
All of the apps. have been given a bit of a makeup, with a new UI. To start off, my first 20min. with the UI has not been very enjoyable. After using it for a few days, I must say that the Usability people working at M$ have been doing a great job. The UI is very very responsive (even for a Beta), and the ribbon thing actually does work.
The downside is the first few hours of getting used to the changes are not very plesant (to put it mildly), but once you get over that short term pain -- things start to look up. I like the work esp. in Powerpoint. Working with Tables and Pictures is now very easy - esp. giving the images nice effects that just make it look it that much nicer.
Word-2007 is unfortunately a bit of a memory hog now [beta?], still after persisting with the new interface - I'm starting to see the whole point behind the changes. There are a lot of tasks that are now a bit more accessible (actually you now know they are available).
Excel has a number of minor tweaks to its Usability. Charts and scrolling are much much better now. The Excel charts can be given that 'pro' look without too much effort :)
Bottom line: If you plan on moving to Office 2007, invest a few hours into the new UI and it will slowly start to grow on you.
Business case: This is a much harder .... I just cannot see enough new features in the product that will make businesses move to the new product line. The UI will most certainly require users to undertake some level of training, the hardest bit to get over is the complete lack of a menu-bar. Habits are hard to change, my feeling is that the final version will most likely have the menu-bar put back in just to make users feel a bit more at home. A lot of companies are still using Office-10, some have moved to Office-11 fewer still will move to Office 12.
-- Rajesh
Wednesday, May 31, 2006
Deleting a shortcut in Windows Vista...
It now takes 7 glorious steps to delete a shortcut.
I'll post a longer rant about Windows Vista in a few more weeks (once I've had a good run with it). At this point in time there are a lot of gaps -- mostly in terms of polish and making it consistent.
Short summary of stuff so far:
1. Plan on 2Gb of RAM. It will run on 1Gb fine -- just like XP does on 512Mb. Then again it is Beta, so maybe 1Gb will be sufficient.
2. UI is still not polished, some dialogs have the old look&feel - I do not know why this is the case. But, my guess would be that there is code that directly draws the UI rather than use Win32/Aero API. This I'm certain will be corrected.
3. The so called protection features are a tad annoying, I'm most certain that they will be pretty much crippled either by M$ or by the user in the first few weeks of using it.
4. The bulk of the annoying bits are really to do with UI being inconsistent, rather than the underlying technology.
5. I've had a few problems getting Networking working properly.
6. There is still some artifact noise when dragging windows around, flipping between Windows etc. At times the whole UI becomes very very slow -- then it decides all is OK and starts being more responsive. [This again is a Beta issue, will probably change soon]. I noticed this when I was running a few apps. and tried moving between Windows when compiling a large application.
7. If the rumors of them charging US$450 for the Home-Ultimate edition are true -- this beast of an OS will never really take off. Considering that the average price of a basic PC is around US$600 -- anything more than US$100 for the O/S will be just not work.
8. Firefox runs faster and better than IE7. I hear IE8 is now the Firefox killer...
I just started to realise how polished XP really is, after playing around with Vista.
I'll post a longer rant about Windows Vista in a few more weeks (once I've had a good run with it). At this point in time there are a lot of gaps -- mostly in terms of polish and making it consistent.
Short summary of stuff so far:
1. Plan on 2Gb of RAM. It will run on 1Gb fine -- just like XP does on 512Mb. Then again it is Beta, so maybe 1Gb will be sufficient.
2. UI is still not polished, some dialogs have the old look&feel - I do not know why this is the case. But, my guess would be that there is code that directly draws the UI rather than use Win32/Aero API. This I'm certain will be corrected.
3. The so called protection features are a tad annoying, I'm most certain that they will be pretty much crippled either by M$ or by the user in the first few weeks of using it.
4. The bulk of the annoying bits are really to do with UI being inconsistent, rather than the underlying technology.
5. I've had a few problems getting Networking working properly.
6. There is still some artifact noise when dragging windows around, flipping between Windows etc. At times the whole UI becomes very very slow -- then it decides all is OK and starts being more responsive. [This again is a Beta issue, will probably change soon]. I noticed this when I was running a few apps. and tried moving between Windows when compiling a large application.
7. If the rumors of them charging US$450 for the Home-Ultimate edition are true -- this beast of an OS will never really take off. Considering that the average price of a basic PC is around US$600 -- anything more than US$100 for the O/S will be just not work.
8. Firefox runs faster and better than IE7. I hear IE8 is now the Firefox killer...
I just started to realise how polished XP really is, after playing around with Vista.
Tuesday, May 09, 2006
RSS2PDF
Here is a service that is really nifty and most likely of limited use. This website will convert any of your RSS feeds into a PDF. I'm still wondering when I would use it, but just in case you ever need it - do check it out.
Technically, all they seem to have done is create a XSL-Formatting Object that converts the RSS feed into a PDF file, using the Apache FOP library.
Do leave comment if you can find a real use for RSS2PDF.
Tuesday, May 02, 2006
Who will win the next-gen console war?
Nintendo has decided to name their next-gen console "Wii" (pronounced 'We'), it was hyped under the codename Revolution until now. There is a lot of speculation on what will go into this machine, but what is now known is that the controller is innovative and different.
Sony has indicated that PS3 will ship later this year, probably for around US$400. XBox 360 has been around for a little while now, mostly to good reviews.
Who will win?
XBox 360 has the lead, PS3 alledgedly has the best graphics (alledgedly), Wii has the new controller. My take is that if 'Wii' works as advertised in the videos and the controller is indeed simple and fun to use -- they will pretty much sell a lot more units than Sony or M$.
My reasoning is that ultimately consumers will buy a console for game-play, not to replace their home-entertainment system. Not in 2006 anyway -- and Nintendo seems to be pretty much focused on great game play and making their console as widely accessible as possible. Even if they can get 10% more women to start playing their games -- that along will be a huge new market for them.
Sony/M$ seem to be starting on a long path to build 'the entertainment box', and in this regard their product line is really Version 1 and we/they have a long way to go before it will be the 'one box that will rule them all'.
In 12 months we will know...
Sony has indicated that PS3 will ship later this year, probably for around US$400. XBox 360 has been around for a little while now, mostly to good reviews.
Who will win?
XBox 360 has the lead, PS3 alledgedly has the best graphics (alledgedly), Wii has the new controller. My take is that if 'Wii' works as advertised in the videos and the controller is indeed simple and fun to use -- they will pretty much sell a lot more units than Sony or M$.
My reasoning is that ultimately consumers will buy a console for game-play, not to replace their home-entertainment system. Not in 2006 anyway -- and Nintendo seems to be pretty much focused on great game play and making their console as widely accessible as possible. Even if they can get 10% more women to start playing their games -- that along will be a huge new market for them.
Sony/M$ seem to be starting on a long path to build 'the entertainment box', and in this regard their product line is really Version 1 and we/they have a long way to go before it will be the 'one box that will rule them all'.
In 12 months we will know...
Saturday, April 22, 2006
House hunting...
Recently we decided to get into the house hunting game -- this time it was to buy rather than rent. Being 2006, the starting point in Australia is pretty much Realestate and Domain.com. Both great in their own right -- but unfortunately the biggest draw back was I found both user interfaces very limiting -- and almost designed to ensure that you spend as much time as possible on their sites and find as little as possible. I guess they make money by selling ads.
I searched around to see if there would be some nice API, with documentation to help me get to data that would interest me. Sadly, the businesses that operate these sites do not provide such access - so, I ended up hacking up a script that screen scapped the data I was interested in and then pumped out a single page with all of the properties that matched by criteria with just the information I wanted.
Now for the next problem -- I wanted to get a map, and a map that actually indicated which direction the plot was facing. Realestate guys use UBD, this draws a big fat circle to indicate the address -- but nothing much else. Victorian Land Office does have wonderful information including the plot size, the direction it is facing and a whole bunch of other useful information -- but this is on yet another site. Surprise, surprise -- no easy to access API for these website.
The good news was that Street-Directory, did provide a map with an indication of the direction the land was facing, but still no details on the size. Realestate agents provide a vauge (mostly positive) snippet about the house -- pretty much in marketing speech. So I modified my screen scapper to plug into Street-Directory maps to get the additional information. During this experiment I also found out that Microsoft Maps provide street level maps for Australia, with documentation that tells one how to get the map -- with one catch, you cannot take the image it splits out, you actually need to hook into the page it generates.
So, current status:
* A hacked up script that gets useful information from RealEstate and Street-Directory all on a single page.
Wish list:
* A web API for RealEstate and Domain (even it is a WSDL ~ I'll accept it, with regret)
* A document from Street-Directory about their API, I've worked out most of the keys
* An API that opens up the Victorian Land Data
* The API that provides the planning permits/house details from the local council
Just incase you are wondering about privacy issues, all of this is currently available for free -- just from 4 different websites, which at their own discretion may change the look and feel of their applications breaking my scripts. And if the fee is nominal, I would even pay to use this API.
I never did understand the power of Mashups, Web-Service .. until now.
I searched around to see if there would be some nice API, with documentation to help me get to data that would interest me. Sadly, the businesses that operate these sites do not provide such access - so, I ended up hacking up a script that screen scapped the data I was interested in and then pumped out a single page with all of the properties that matched by criteria with just the information I wanted.
Now for the next problem -- I wanted to get a map, and a map that actually indicated which direction the plot was facing. Realestate guys use UBD, this draws a big fat circle to indicate the address -- but nothing much else. Victorian Land Office does have wonderful information including the plot size, the direction it is facing and a whole bunch of other useful information -- but this is on yet another site. Surprise, surprise -- no easy to access API for these website.
The good news was that Street-Directory, did provide a map with an indication of the direction the land was facing, but still no details on the size. Realestate agents provide a vauge (mostly positive) snippet about the house -- pretty much in marketing speech. So I modified my screen scapper to plug into Street-Directory maps to get the additional information. During this experiment I also found out that Microsoft Maps provide street level maps for Australia, with documentation that tells one how to get the map -- with one catch, you cannot take the image it splits out, you actually need to hook into the page it generates.
So, current status:
* A hacked up script that gets useful information from RealEstate and Street-Directory all on a single page.
Wish list:
* A web API for RealEstate and Domain (even it is a WSDL ~ I'll accept it, with regret)
* A document from Street-Directory about their API, I've worked out most of the keys
* An API that opens up the Victorian Land Data
* The API that provides the planning permits/house details from the local council
Just incase you are wondering about privacy issues, all of this is currently available for free -- just from 4 different websites, which at their own discretion may change the look and feel of their applications breaking my scripts. And if the fee is nominal, I would even pay to use this API.
I never did understand the power of Mashups, Web-Service .. until now.
Wednesday, April 19, 2006
Clean up whtieboard photos..
Scanr takes any photos taken using a mobile phone (or) digital camera of the whiteboard and then cleans it up + provides a more useful JPG. They even have a version that can do some OCR given a good quality photo of a printed-document.
For the last few years, I have been pushing the Agile practice of creating models on the whiteboard - till we start writing code. The only pain was that previously the photos were mostly posted directled as taken by the camera. However, I have always felt the need for a solution that would just clean up these pictures by applying some basic image filters on it.
It seems simple enought to use, but I do not know their business model and how they plan to survive -- so let us hope for the best.
-- Rajesh
For the last few years, I have been pushing the Agile practice of creating models on the whiteboard - till we start writing code. The only pain was that previously the photos were mostly posted directled as taken by the camera. However, I have always felt the need for a solution that would just clean up these pictures by applying some basic image filters on it.
It seems simple enought to use, but I do not know their business model and how they plan to survive -- so let us hope for the best.
-- Rajesh
Subscribe to:
Posts (Atom)