There are some software engineering authors, that I really appreciate. Paul Graham, Martin Fowler, Joel Spolsky are some of them. This post is just for Joel Spolsky. He has a good sense of humor. He writes complex ideas in a very simple to understand manner. And his texts are good to learn english :) Therefore I read him with pleasure.
Sunday, January 22, 2006
Sunday, December 25, 2005
Richard Hamming: You and Your Research
I read a great article on having ambitions and pursuing after them. It has many surprising but very smart lessons. I cut and pasted some parts of this long article below. (I hope the author doesn't mind this :))
In summary, I claim that some of the reasons why so many people who have greatness within their grasp don't succeed are: they don't work on important problems, they don't become emotionally involved, they don't try and change what is difficult to some other situation which is easily done but is still important, and they keep giving themselves alibis why they don't.
...
One of the characteristics of successful scientists is having courage. Once you get your courage up and believe that you can do important problems, then you can. If you think you can't, almost surely you are not going to.
...
When you are famous it is hard to work on small problems. This is what did Shannon in. After information theory, what do you do for an encore? The great scientists often make this error. They fail to continue to plant the little acorns from which the mighty oak trees grow. They try to get the big thing right off.
...
``How can anybody my age know as much as John Tukey does?'' He leaned back in his chair, put his hands behind his head, grinned slightly, and said, ``You would be surprised Hamming, how much you would know if you worked as hard as he did that many years.'' I simply slunk out of the office!
...
What Bode was saying was this: ``Knowledge and productivity are like compound interest.'' Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former.
...
The steady application of effort with a little bit more work, intelligently applied is what does it. That's the trouble; drive, misapplied, doesn't get you anywhere. I've often wondered why so many of my good friends at Bell Labs who worked as hard or harder than I did, didn't have so much to show for it.
...
There's another trait on the side which I want to talk about; that trait is ambiguity. It took me a while to discover its importance. Most people like to believe something is or is not true. Great scientists tolerate ambiguity very well. They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory. If you believe too much you'll never notice the flaws; if you doubt too much you won't get started. It requires a lovely balance. But most great scientists are well aware of why their theories are true and they are also well aware of some slight misfits which don't quite fit and they don't forget it. Darwin writes in his autobiography that he found it necessary to write down every piece of evidence which appeared to contradict his beliefs because otherwise they would disappear from his mind.
...
For those who don't get committed to their current problem, the subconscious goofs off on other things and doesn't produce the big result. So the way to manage yourself is that when you have a real important problem you don't let anything else get the center of your attention - you keep your thoughts on the problem.
...
If you do not work on an important problem, it's unlikely you'll do important work. It's perfectly obvious.
...
We didn't work on (1) time travel, (2) teleportation, and (3) antigravity. They are not important problems because we do not have an attack. It's not the consequence that makes a problem important, it is that you have a reasonable attack.
...
The great scientists, when an opportunity opens up, get after it and they pursue it. They drop all other things.
...
I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don't know quite know what problems are worth working on;
...
The technical person wants to give a highly limited technical talk. Most of the time the audience wants a broad general talk and wants much more survey and background than the speaker is willing to give.
You should paint a general picture to say why it's important, and then slowly give a sketch of what was done
...
John Tukey almost always dressed very casually. He would go into an important office and it would take a long time before the other fellow realized that this is a first-class man and he had better listen.
He is going to dress the way he wants all of the time. It applies not only to dress but to a thousand other things; people will continue to fight the system.
...
I am an egotistical person; there is no doubt about it. I knew that most people who took a sabbatical to write a book, didn't finish it on time. So before I left, I told all my friends that when I come back, that book was going to be done! Yes, I would have it done - I'd have been ashamed to come back without it! I used my ego to make myself behave the way I wanted to. I bragged about something so I'd have to perform.
The link to the article: http://paulgraham.com/hamming.html
Monday, August 15, 2005
A Piece of Lean Thinking in Software Development
There are two ways doing things when developing software:
1. Collect the related things to do. Process all the related work together.
2. When started an activity go deeper whenever required without putting work into backlog.
Actually these two ways of doing things are very general. They may be applied to any kind of activity. But let's continue with software development.
During coding I need to open several parantheses in my head in order the whole module to function properly. Sometimes I postpone them until I finish the current work. But when I finish the work, I forget the postponed activities. So I go on with some other activity, that I can remember. After finishing all the remembered activities, I build and run the software, but it crashes usually. I go back to the point that I had postponed.
But sometimes I do things whenever I see the need to do it. This is safer at the end. But it requires a lot of memory too in order to return back, where I stayed.
Lean thinking suggests to do things one-by-one. Backlogs and work in process inventories are harmful since they delay the whole project.
I believe this is true. But our habits are somehow against it.
Thursday, August 04, 2005
Architecture - Objects - Layering etc.
Architecture solves lots of problems. Sometimes I have to spend lots of time on debugging when I add new features to a software. But there are times that I write code without interruption of bugs. This is due to architecture. Architecture solves lots of problems implicitly saving us from debugging the bugs.
One big problem is bad layering. UI, data access, business logic, security and other functionalities are all in one module (I use module in the sense of a whole unit. It may be a function, class or package.) Then lots of problems arise due to mismanagement of data or objects.
A big issue that I encounter for the last few days is the coordination of objects' references. There is a huge network of objects. But some of the objects are rotten, that is they are not up to date with the database. But they are referenced by the UI or business layer.
I will continue as always :) A friend has arrived...
Tuesday, August 02, 2005
User Interface Design and Being Agile
There is a very interesting problem that Dave Churchville blogged on: Can user interface design be agile?
He says, by being agile you develop iteratively. You listen the customer a little then develop some of the functionality rapidly. Then you make a meeting and customer gives some more feedback.
This is a very valid and effective system. But this style of development brings us to a point, where we cannot understand the actual goal of the users. Instead of building empathy of the user's actual needs, we got to constrain ourselves on the words only. This is good on the one hand. The user steers the project. But there is always a tacit knowledge that the user is unable to express.
I will try to write more on this. Now, I have to go home :)
Sunday, July 31, 2005
Google Map
I liked Google Map a lot. It is unfortunate for us that it doesn't cover Turkey yet. Geographical applications will probably increase their share in the future.
We will be able to locate any address, institution through this map applications. 3rd party applications on Google Map will soon emerge. Now it is our turn as developers. We should find new ideas of applications of Google Map.
Geography and GIS related Blog
I saw GisUser's weblog inside the popular blog list of blogger. It is a great resource for people interested in geographical technologies. The link is: http://gisuser.blogspot.com
Saturday, July 30, 2005
So many appraisals for a bad application
There is a timetable scheduling software called as Mimosa. It is totally unusable. There are lots of buttons in each screen that are totally not understandable by their labels. The labels have spelling errors. The graphical layout is totally unorganized. I think the users must have taken lots of training to be able to do something useful.
But this software is sold to more than 50 countries around the world. The user comments are very appealing. Let me show some of them:
"Thank you very much for your help, the software is excellent for our needs."
--- A.H.S., México D.F., Mexico
"I have tried the software and have experienced thousand easy steps and all possibility options have been fulfilled. Thanks."
--- E.G., Dehradun, India
"Mimosa is flexible and user-friendly. It makes creative timetabling possible at an affordable price."
--- R.M., Gaborone, Botswana
How might this be true? This is totally incredible for me. It is nearly impossible to use this software. How did so many people like it?
w.bloggar does not support unicode
It is sad for me to have learned that w.bloggar -a very useful desktop blogging client- does not support unicode. I can't post in Turkish with wbloggar. I hope they will soon add this feature.
Subscribe to:
Posts (Atom)
