Posts filed under 'Software Development'
Just read Kathy Sierra excellent post about how memory and memorable works when I stumbled upon the next paragraph:
"Remember--your users don't have to be passionate about your product in order to be passionate users. Sometimes--often--users are passionate about what they do with your product. And it's that thing they do where you can help them kick ass. Users who "kick ass" are those who get good enough to reach a state of "optimal experience" doing whatever it is you're helping them do (through your product, service, support, learning, whatever)"
Now that was a very hard to learn lesson, as a tech guy I'm passionate about technologies and too often, at the beginnings, I tried to make the clients see the beauty of the technology behind a product or a solution. The only trouble is that, we live in a complex world and making them see something that takes months, maybe years of study and even more years of experiences is near mission impossible. It still makes a difference as if you really care about those things you can not really hide your passion, and passion, usually creates a kind of trust.
I think I learned my lesson but still, sometimes, not showing or talking about the beauties of a solution or technology leaves me frustrated. The truth is that not the technology matters but what we can do with it.
December 20th, 2005
I cannot point my finger on what exactly I like about Joel, but ideas like this and a perfect implementation are a good hint.
Taking four interns (three in development and one in marketing) and putting together a product from the beginning to the end is just, hm, how to say this a brilliant idea! Or maybe I’m absolutely wrong it’s the right idea.
Just think about it, if you want a new product, it has to be fresh. How do you get fresh ideas? Definitely not from tired, locked on statistics and technologies brains but rather from fresh and young minds. How do you pull a product from beginning to the first launch in 3 or 4 months if not with fresh and young people fully charged with energy and eager to prove themselves?
I was rather sceptic about their first two products, a bug management system (issue tracking) and web editor in a saturated market with both free and commercial products. I still think that if you remove Joel from Fog Creek they would remain with two 20$ shareware products. But this one sounds great, and not because of the technology since it is nothing new, Unix had it since the beginnings of X, VNC is out there from some time and it’s even free, and every version of Windows XP Pro ships with it, yet still they found the market to it, made it a bit simpler (not that it was too complicated) and definitely know how to present it.
As a matter of fact I know now what I like about Joel, he’s cult for simplicity and doing what feel right no matter what anybody else is used to do.
July 9th, 2005
After the first public release of SpaceMapper DataStore and MN8 last week I have some data to draw some conclusions. Unfortunately, on the release date, the FreshMeat announcement contained links which did not passed through the SourceForge counters
(the link was directly to prdownloads instead of the downloads section
on the status page), so I have no Idea about the downloads in the first
day. However seems that there is a lot more interest in an XML database
than in a new scripting language and even so 78% are interested in the
binaries and only 22% in the source of the database project. With the
scripting language the situation is reversed, 79% interest in the
source and only 21% in the binaries. I guess peoples are more
interested in how to write an interpreter than in using a new one 
No feedback, no bugs, no mailing list interest no contributors which is reasonable to a first public release.
What is not reasonable is that the Klez virus on somebody's computer
noticed the release and it sends thousands of virused mails with my
email address in the from. In case anyone receives one I'm really
sorry, it's not my fault, it's not from me and you can verify that by
looking at the source of the message. All the mails I send goes through
our server (194.102.233.6) which I'm sure you won't find in the
received headers.
November 11th, 2002
So after finishing the first fully functional internal release of mn8 we considered that running mn8 on a web server side is also useful so we started to make a servlet which will run mn8 based scripts and concepts.
A couple of days should have been enough, still it’s not ready. When I started I tried to make an accurate picture of the steps involved in order to try to improve the estimated time.
The reasons are: a malfunction of the custom scheme based url’s when mn8 is run inside Tomcat and a synchronization problem as now multiple mn8 scripts can be run concomitantly inside the same Java instance.
The synchronization issue could have been foresaw but the Tomcat thing not.
So, what takes to make accurate project estimates, experience ?
May 18th, 2002
The .net guy started a discussion on this topics so here is my experience/ideas on this.
Unit Tests
I could not live without them . Since I read Fowler's book about refactoring I'm using unit tests everywhere where I have more than 10 classes both at the company as at home.
It's panic when the number of features without unit tests increases
(lack of time, or very urgent things to solve, I know unit tests first
...). It's relief when you are fully covered. What I like most about
using unit tests is that it gives you really speed. You can hack freely
and at the end if the unit tests pass you are OK, ready to make the
commits.
It is not universal panacea but it really eliminates the small and
medium bugs, and seriously prevents introducing new bugs while
changing/refactoring things.
However it does not eliminate complex bugs (the hard to catch and
fix type) but even so once those are fixed prevents them from
reappearing.
This is from experience, not theory. I use tests for over a year
now, and I wouldn't go back. I can not imagine a stable medium or large
project without unit tests, mainly because I don't believe it could
exists.
Pair programming
Pair programming does wonders for the code and most of the time for
the coders to. It's an excellent idea with excellent results and with
only one but. The human factor. It's very difficult to impose pair
programming in a team except for short periods of time, even if
everybody acknowledges the merits.
People everywhere have good and bad days, and pair programming
requires patience therefore doesn't work very well when there are too
many bad days involved and that is basically the reason I have said
that it doesn't work for long periods of time (At least I didn't
managed to make it work in my company 
Still we are using it constantly and happily in the next situations:
- One team member has a too long dark period and seems unable to get
out of it by himself. Making it work in a pair will get it back again
in a maximum of two days, days in which is producing good code
- There is some kind of knowledge transfer needed. Either you
are new to a part of the code or functionality or you just want to pass
one some best practices, pair programming does wonders.
- The needed functionality is a bit too complex and you are
uncertain about your ability to make it in time at a wanted quality.
Having a strong partner does wonders again. It's an excellent panacea
for "Analysis Paralysis"
From experience a pair produces more than two individual programmers
at a lot better code quality. Sure there are exceptions, but that has
to do again with the human factor.
Who knows maybe in time will become the defacto way of coding, just
like coops use to work in pairs but that is a bit too far away as I
see it.
April 8th, 2002
We said six months and it will be one year when the first phase of the project will
be over. That means 100% late. True it is a bit of an research project
and the number of features needed and implemented for a pleasant
release is double than the initial proposal. Still how could I be this
wrong?
Since I've been leadering at my old company I use to keep a time
registration. What I notice is that for 80% of the tasks I have to do
I'm bellow or there with the estimation. But with the remaining of 20%
I'm chaos. Actually there is all the extra time. Maybe one day I will
have enough information and I will manage to find all the correlations
about the type of tasks or maybe the sphere of the tasks which are
rebelling my management .
March 19th, 2002
In 14 March we will have one year since we actually started the coding on
all of the "SpaceMapper" projects, a very difficult one but full with
rewards.
So, I took JMetric
and I did a couple of measurements on mn8. Here are the results:
- Lines of code: 20311
- Statements: 14218
- Classes: 211
- Methods: 2296
- Variables: 981
- Public Methods: 1877
This is just the code, no documentation, no unit tests, just the core java
source files. This was till recently a man/month effort. With the actual
code started only from August, till August I was working on the prototype.
Not bad, I guess.
I only have two features open with
one task in each so I'm really at the
end of a first serious release. It's not a bad feeling but it is not good
either, it's exhaustion, accomplishment and scare. In a couple of days/weeks
your secret will be publicly exposed. It's like having a child and giving
it away to strangers to take care of him.
Enough of this mumbling this is not what I had to say. I was about to tell
you about testing and bugs.
The last two months among closing the remaining features we started
intense testing. What I found is that bugs comes in layers. Three
particular type of of bugs, each type with it's own schedule.
The first layer is the soft and easy bugs. Plenty of them, quick to catch
and fix. Unit tests are great investment for this layer.
Then it comes the more complex layer. Not difficult to find but a bit more
trickier to fix. Most of this bugs can be catched by unit test and can
easily be kept under control for the future, again through the unit tests.
But then comes the last layer, at the end when, you are really tired and
seek of bugs. These bugs are nasty ones. Very hard to catch, very hard to
reproduce, very hard to understand what the hack is going on. Should I
mention about fixing them? I spent the last two days chasing such a bug,
I'm not there yet, but I will. Sometimes I wonder if it is a good idea at
all to spend so much time for just one bug?
Unit tests won't help you with these bugs, except maybe after you fixed
them to make sure don't reappear.
Also was interesting to notice that whoever said that 80% of bugs are situated in 20% of
code was absolutely right. The majority of bugs where around 3 classes which where
extremely complicated. Hard to believe that 80% of the bugs where actually in around 200
lines of code from 20,000. The problem is that when I designed those particular portions
of code I was aware of the grade of difficulty exposed so I tried to code in the way Kent Beck recommends and explicitly
expressing intention. All this by using meaningful names, breaking the code in many
minuscule methods and so on. Still, even if was a lot easier that way to understand
functionality it continues not to be extremely easy.
Another interesting conclusion was that even if at the beginning all of us blame somebody
or something else, always, and I mean always we are the stupid ones, and probably the
debugging time would be reduced considerably if we would always start checking the code
instead of trying to catch what we imagine is happening which almost always is miles away
from what is actually happening.
March 5th, 2002
How non-programmers use documentation an interesting thread at Advogato.
Would be maybe more interesting to find first what kind of user
categories are out there. I know I found myself such users who
had to write down all the steps for sending an email. But those
users where maybe prime time computer users (I know for sure that
they where) and it was a rare phenomenon. Not writing
documentation at all because some don't use it is not a choice.
Knowing well who are your target users might help you identify
what kind of documentation to write. There might be no point in
writing stories for experienced computer programmers but it
would make sense to do that to casual computer users.
So, identifying user stereotypes might be a good idea, but
unfortunately a search on Google revealed no statistics but a
couple of jokes
and some research documents related to modeling
user stereotypes.
Anyway, maybe a good start to good documentation is writing it
well. And
here is a paper much appreciated on this subject.
There also seems to be some ISO standards for writing user
documentation:
- IEC 18019
Guidelines for the design and preparation of software user
documentation - ISO/IEC 9127
User documentation and cover information for software
packages - ISO/IEC 15910
Software documentation process
But then again, these documents are not for free 
Leafing about Microsoft is not a good idea. Usually these
companies has put lot of money in usability and user behavior
research and this is good. I don't use their help system (hell I
don't even use their operating system) but most of the users do
(how much of the desktop systems they own?) and even if some of them
complain most of the users are able to use it.
Some companies even publish the result of this researches so why don't we take
the opportunity and learn something on their expense
November 10th, 2001
At around 10 PM a felt the need to go home, this is very
rare. Then, I knew why I did it! I always felt and believed
that there is a reason for everything happens in my life,
even if sometimes is a bit hard to find or understand it.
So I went home, I started the TV and switched to National
Geographic (documentary channels are very popular here in
Europe), and guess what was running ? Code Rush ! The
documentary made about the Netscape company before and after
Mozilla. It was cool. For the first time I saw how JWZ is
looking, weird ,
The conclusions ? Hey programmers everywhere feel and work
pretty much in the same way! Lost nights, hopes, frustration,
endless study and coding, .... Another conclusion! Netscape,
despite all what happened, ended reasonable. I mean the code
is out (Open Source), so it's good for community, and it
made quite a few of millionaires. It could have been worse.
Personal Code Rush
Usually we go with Agile kind of development methodologies,
which basically means we don't do huge upfront design, just
enough to get the picture and start a first iteration, and
the we code along. This worked quite well until now, with
our previous projects, but seems that is not universal
panacea.
I'm working right now on an cute scripting language and it
worked out quite well, up to a point when it became obvious
that the design was not quite correct. This usually happens,
and can be solved with a small refactoring. Well it turned
out the refactoring needed is not that small after all.
A couple of days on the drawing board produced the correct
design (at least it seems correct). The morale of the story
? Be careful, not everything can be done in small
iterations and still be economic. To be honest if I would
stick to the book, religiously, the problem might have been
corrected in time, but that is the problem with Agile methods
and XP, how many stick to the book exactly?
September 10th, 2001
