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.
Monday, August 15, 2005
A Piece of Lean Thinking in Software Development
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 :)
