Eat your own dog food
This saying states that you should use your own products internally, as much as possible. Not only does this show pride in your work, but you also get to know your product from the user's point of view. Every company should do this, and this way you can get a first hand experience of how to improve the software, what other features to add, and whether those "life-altering" features that you decided to add, actually alter the user's life for the better.
One should not shy away of using the products, and also checking their compatibility issues with other products. It is quite unfortunate that people who build software for specific reasons, that they cannot use them each and every day. It might be an adequate punishment in Dante's Inferno ,seeing some software developer having to use their own software each and every day. If you were to be the one using that software each and every day, maybe you would put less images, and bigger text. Or maybe you would make that airplane boarding software less fancy, and more responsive. Or maybe you would make that online booking system less Web 2.0, and more reliable.
And even if at the end of the day you get to use your own software, and you like it, do not forget the blind people, or colour blind individuals, or people who have problem using a mouse, or people who do not understand your main language....
if everyone working in software were to consider a bit more the users, and as many of them as possible, I am sure that the quality of it would greatly improve.
Wednesday, March 26, 2008
Monday, March 17, 2008
Open Source
Open source! One of the best inventions, ever! If you do not know what it is, or you think you know what it means, but are not really sure, read the article in Wikipedia, and then continue reading here. A difference one must understand is in the definition of free software. Free can be in the sense of free beer, and it can also be in the context of free speech. What I am really interested in is as in free speech ( although free software is a very good idea too).
An interesting article is this one.
Open source is a good way of testing your own skills, and of getting involved. It helps you stop whining about the current state, and actually do something about it. Also the software can be trusted a bit more, both because you can avoid malicious coders, and by knowing how secure it is. Also you feel more product ownership in something you helped create. However most products you use are not created by you, but you can feel better by knowing that you can modify them, understand them, and upgrade them easier.
In open source you get a natural society, where everyone works for the common good, and also people help each other, and try to build a superior product, to improve people's lives.
This ideology can be used in way more places than software development. Open source religions already exist, maybe politics is the next logical step? We need to keep evolving ourselves, and even our ideas. As Bill Hicks used to say, "You know, evolution didn't end with us growing thumbs".
An interesting article is this one.
Open source is a good way of testing your own skills, and of getting involved. It helps you stop whining about the current state, and actually do something about it. Also the software can be trusted a bit more, both because you can avoid malicious coders, and by knowing how secure it is. Also you feel more product ownership in something you helped create. However most products you use are not created by you, but you can feel better by knowing that you can modify them, understand them, and upgrade them easier.
In open source you get a natural society, where everyone works for the common good, and also people help each other, and try to build a superior product, to improve people's lives.
This ideology can be used in way more places than software development. Open source religions already exist, maybe politics is the next logical step? We need to keep evolving ourselves, and even our ideas. As Bill Hicks used to say, "You know, evolution didn't end with us growing thumbs".
Friday, March 14, 2008
Psychology and IT
There two fields are closer than one thinks. When studying Computer Science and Artificial Intelligence, I had to cover many topics that fall under psychology. From how human memory works, to neural networks. From communication, to language learning and acquisition. However another area where it is of massive importance is at the workplace. it is of vital importance to remember that at the end of the day, we are working with human beings, who have dreams, feelings and agendas. Their language is ambiguous, and their APIs are inconsistent. Their IDE tends to be hard to use, and sometimes what they say is hard to compile ( or rather interpret ). Humans also do not have one generic protocol for communication, and their source code is unmaintainable.
Which is where the psychology kicks in. One needs to wear extra gentle gloves when dealing with humans, and also, one must not forget his or her own feelings and problems. Projects do not only fail because of lack of knowledge of the available technologies, or because of coding standards. Projects also fail because of human nature. Some people find it hard to get along, other absolutely cannot work together. Some people are hard to understand, while others suck at team work. Everyone has a personal character, and when working with such people, get to know their "documentation" and their "API calls", because ( and trust me on this) you'll need them later.
Recently I was trying to explain to friends of mine ( who do not work in IT) what a retrospective is. The reactions this got were mixed, and they ranged from people not believing it works, to people not believing it is needed.
From my personal experience, I find these little exercises to work. it is good for a team, as a whole, and as a new temporary family, to try these exercises together, because after all, improving the team structure and internal working, will improve how the team works as a whole.
It is good to know what other people did.
it is good for other people to know what you did.
It is good for every team member to feel appreciated.
It is good to see that past failures are being worked on.
It is good to get your voice heard.
It is good to take a short time off, and reflect.
It is good to learn from past mistakes, otherwise they are lost.
It is good to laugh together, as a team.
And finally, it is always to look back, before looking forward. This is why the Roman god Janus has two faces, facing different directions.
Which is where the psychology kicks in. One needs to wear extra gentle gloves when dealing with humans, and also, one must not forget his or her own feelings and problems. Projects do not only fail because of lack of knowledge of the available technologies, or because of coding standards. Projects also fail because of human nature. Some people find it hard to get along, other absolutely cannot work together. Some people are hard to understand, while others suck at team work. Everyone has a personal character, and when working with such people, get to know their "documentation" and their "API calls", because ( and trust me on this) you'll need them later.
Recently I was trying to explain to friends of mine ( who do not work in IT) what a retrospective is. The reactions this got were mixed, and they ranged from people not believing it works, to people not believing it is needed.
From my personal experience, I find these little exercises to work. it is good for a team, as a whole, and as a new temporary family, to try these exercises together, because after all, improving the team structure and internal working, will improve how the team works as a whole.
It is good to know what other people did.
it is good for other people to know what you did.
It is good for every team member to feel appreciated.
It is good to see that past failures are being worked on.
It is good to get your voice heard.
It is good to take a short time off, and reflect.
It is good to learn from past mistakes, otherwise they are lost.
It is good to laugh together, as a team.
And finally, it is always to look back, before looking forward. This is why the Roman god Janus has two faces, facing different directions.
Tuesday, March 11, 2008
Unexpected problems
Sometimes we set off to take a very big task, and prepare ourselves for the worst. We look at certain areas that we think to be hard, and expect a lot of problems to arise from them. However, ironically, the biggest problems arise from areas we thought to be hard, or else from areas we did not even think might pose problems.
So much just like real life. After worrying a lot about something, what really hits you hard, is what you did not even consider to ever be a problem. Just as said in this song...
" Don't worry about the future. Or worry, but know that worrying is as effective as trying to solve an algebra equation by chewing bubble gum. The real troubles in your life are apt to be things that never crossed your worried mind, the kind that blindside you at 4 p.m. on some idle Tuesday. "
Well, in my case, I have two example in my head right now. These are Unicode, and TimeZone issues.
When working on data, many times you get stuck on issues related to Unicode, and this is why it is a very good idea to read about it beforehand.
And when working on getting data from across the globe from point A, and then handle it in a script on point B, store in a database in point C, and then read it from points D and E, it is good to know about timezones, and think beforehand how to standardize this data, and also when the data is updates, and when the peak times are in those areas.
Just my two cents...
So much just like real life. After worrying a lot about something, what really hits you hard, is what you did not even consider to ever be a problem. Just as said in this song...
" Don't worry about the future. Or worry, but know that worrying is as effective as trying to solve an algebra equation by chewing bubble gum. The real troubles in your life are apt to be things that never crossed your worried mind, the kind that blindside you at 4 p.m. on some idle Tuesday. "
Well, in my case, I have two example in my head right now. These are Unicode, and TimeZone issues.
When working on data, many times you get stuck on issues related to Unicode, and this is why it is a very good idea to read about it beforehand.
And when working on getting data from across the globe from point A, and then handle it in a script on point B, store in a database in point C, and then read it from points D and E, it is good to know about timezones, and think beforehand how to standardize this data, and also when the data is updates, and when the peak times are in those areas.
Just my two cents...
Wednesday, March 5, 2008
About me
The most dreaded question, in my humble opinion, within a job interview, is when they look you straight in the eyes, and ask you, "So, tell us something about yourself." This question is normally meant as an ice breaker, and also as a way to give a synopsis of your character. From here normally one tries to understand a person's background, which means from where a person is coming, and also where a person is going.
I despise this question for the simple fact that I do not know how to summarise my life, my achievements, my past, present and future, in a single straight answer. This for me, is nothing short of impossible. So normally I start with my name, education, some characteristics, and then start to stumble about dreams, wishes, ... and this is where they normally interrupt me to start asking other questions, some which are even more dreaded, like... "What is your worst character trait?"
But well, it is good and practical to be able to describe yourself. Whether it is to do so at a cocktail party, in an interview, or on a blog, it is something one should be capable of doing. So let the description begin.
I consider myself to be a smart person. I am also very entushiastic. I love challenges and I love problem solving. I do not know everything in life, but what I lack in knowledge, I make up in curiosity.
I am a very friendly person, and this is said not just by me. All team members I have worked with have commented on this. I really appreciate this. I believe that every person should help those around him to have a better work environement. And a good way of doing this, in my opinion, is by being a cheerful person. Something is bound to go wrong, always, in any environement. Projects fail, people clash, and sometimes these happen in the worst timing possible. So a good way of dealing with all this, is by being a friendly person. A smile would help, and also sometimes cracking a joke. Lightening the mood will help those around you, and also their relations towards you.
I also appreciate people who are friendly, and enviroments that help such people succeed. Some places just kill that joy within people. Try never ever ever to work in such a place. Your personal happiness is worth much much more than that.
You should work to live, not live to work.
I despise this question for the simple fact that I do not know how to summarise my life, my achievements, my past, present and future, in a single straight answer. This for me, is nothing short of impossible. So normally I start with my name, education, some characteristics, and then start to stumble about dreams, wishes, ... and this is where they normally interrupt me to start asking other questions, some which are even more dreaded, like... "What is your worst character trait?"
But well, it is good and practical to be able to describe yourself. Whether it is to do so at a cocktail party, in an interview, or on a blog, it is something one should be capable of doing. So let the description begin.
I consider myself to be a smart person. I am also very entushiastic. I love challenges and I love problem solving. I do not know everything in life, but what I lack in knowledge, I make up in curiosity.
I am a very friendly person, and this is said not just by me. All team members I have worked with have commented on this. I really appreciate this. I believe that every person should help those around him to have a better work environement. And a good way of doing this, in my opinion, is by being a cheerful person. Something is bound to go wrong, always, in any environement. Projects fail, people clash, and sometimes these happen in the worst timing possible. So a good way of dealing with all this, is by being a friendly person. A smile would help, and also sometimes cracking a joke. Lightening the mood will help those around you, and also their relations towards you.
I also appreciate people who are friendly, and enviroments that help such people succeed. Some places just kill that joy within people. Try never ever ever to work in such a place. Your personal happiness is worth much much more than that.
You should work to live, not live to work.
Friday, February 29, 2008
More links
Today I shall be mentioning some more links that I like to check up on frequently.
http://www.lecturefox.com/
This links is a good way to stay up to date with lectures from different universities from around the world. Contains video, audio, and text material.
http://msdn2.microsoft.com/en-us/library/aa338218.aspx
Different papers released, that contain some data about .Net framework, and also some algorithms.
http://www.mindhacks.com/
A blog, that is updated very frequently, with different topics from psychology.
Check them out. Quite interesting.
http://www.lecturefox.com/
This links is a good way to stay up to date with lectures from different universities from around the world. Contains video, audio, and text material.
http://msdn2.microsoft.com/en-us/library/aa338218.aspx
Different papers released, that contain some data about .Net framework, and also some algorithms.
http://www.mindhacks.com/
A blog, that is updated very frequently, with different topics from psychology.
Check them out. Quite interesting.
Thursday, February 28, 2008
The science of testing (and debugging)
First the question needs to be defined. In our case this means that during testing, be it Black box or White box, one needs to know what is going on. What am I looking at? What is it supposed to be doing? Is it doing what it is supposed to be doing? A system can very easily do the wrong thing in a very good manner. In such a case, the testing is said to have failed nonetheless.
The obervation part is the actual testing. Here yo uare expected to interact and observe the system itself, noting down what is happening, measuring the results, and all this without inflencing the actual execution.
Then the hypothesis comes. From the previous data, you see whether the test has failed or not. If it succeeds, you understand why. If it fails, you need to understand why too. You might need to rerun some tests.
The fourth step refers to performing the experiments and collecting the data. Try toggling some setting. See when the results are the same, and what is common in all. This is like detective work, and this is where bright mings normally start to shine and be seen as the geniuses they are.
Now we need to analyze the data. When many programmers, QA people, testers, or any other person, looks at the facts, they all see the same data. But the information is not the same to all. To some the problem is hard to find, and they are as short sighted as bats. While some other person would scream "Eureka", and go rummaging through some forgotten folder, tweak with some random setting that is forgotten by all, and smile at seeing the bug solved, while others just stare at his face asking what the hell just happened.
This contains all the last steps. One needs to come up with a hypothesis, try to dis/prove it, and act on the results.
As usual, science helps us in al situations. =)
Subscribe to:
Posts (Atom)
