1,300 Iraqis Killed in Past Week
Hundreds of unclaimed dead lay at the morgue at midday Monday — blood-caked men who had been shot, knifed, garroted or apparently suffocated by the plastic bags still over their heads. Many of the bodies were sprawled with their hands still bound — and many of them had wound up at the morgue after what their families said was their abduction by the Mahdi Army, the Shiite militia of cleric Moqtada al-Sadr.
A few old usenet postings:
I guess not many people usenet anymore, here are links to some of my past
I just read a great Blog entry of Jim Shore about Software Rewrite. I like many have been in situation when I just wished that if we could redo, the application would have been much better. As some people say always do things twice
and throw away your first try. However, when you are working on a large
complicated software, despite the temptation it can be enormous effort.
According to Jim, If your platform or language does not change, dont’ throw
away your code instead refactor or redesign to work with existing software.
I have heard similar advince from Joel Spolsky. I have been involved with a few
projects with complete rewrites. In early 90s, there was widespread use of
the term “Re-engineering”, that related with business re-engineering and
encompassed a lot of rewrites of software. Later, I was involved with an
ITS project for Illinois Department of Transportation, where we rewrote old
CTIC project, which was written in C/UNIX and wrote new system
GCM Travel in C++/Java/CORBA. It
turned out to be major effort and over budget and years late. Unlike
private company, the government had plenty of tax dollars to keep spending
on the project. When I was at United, I worked on prettty badly written
software and I had to decide whether to continue with the software or rewrite.
I opted for incremental refactoring because unlike CTIC project, I had to
not only write new version, but had to maintain old software. It is terribly
risky strategy to maintain two versions of software. Martin Fowler also has
Pattern he describes for rewriting software. Unfortunately, I am
currently involved with another grand rewrite project (it was started
before I joined). It also has requirement to maintain two different
versions of the software and I can see a lot of time will be spend on
integrating two different versions. I have already seen people taking
short cuts to finish the project and before you would know it, it is
going to follow same road that previous project did.
Finished Personal and Company’s Web Redesign
Since I moved my personal website from my school to my own domain back in 1998,
I did little touch up. So, I finally spent some time to change the looks. I
then realized my company’s website can take a new look too as that has not been
changed since around the same time. I wanted to keep both sites easy to
maintain without any dynamic content management, so I used same technique
that I have been using over ten years, i.e., wrote some templates and created
Ruby scripts to generate html files. It’s not state of the art, but given
my server isn’t too powerful, I think it will work.
Since Fowler’s Refactoring book and adaption of the this term
in the agile community, everyone is board on refactoring. It’s a great
tool to prevent stale code. An ability to adapt to change is a survival
for any business and you continuously need to align your software to make
sure it can change with speed of the business.
Strictly speaking, refactoring is modifying a code without changing external
behavior. Often at the end of release cycles, developers apply quick
hacks to finish the deliverables. Most agile environment dedicate a
few days after each release to clean up the code. Many also use a geek
week after a couple of iterations to do this refactoring or make
structural changes to the aplication.
The point of my rant is two fold refactoring: types of refactoring and when
to use refactoring.
A software needs to continuously adapt and
modify as business requirements change, however I find people use the
term refactoring too loosely. I consider refactoring a minor change in
the code without breaking the contract, however every day I hear people
use the term “refactoring” when they mean redesign, rearchitect or completely
rewrite the software or a piece of software. I acknowledge it’s very cool
word, but I find it nauseating when it’s used improperly. I have seen a
number of projects that start from modest size with a couple of average
developers to large size. In many cases the code is not properly maintained
(or refactored) until it simply fails to meet customers’ expectation. So,
they will start to addressing the design or architecture issues that
are at the heart of proplem and start making major changes in the software.
Such effort of major redesign or rearchitecture cannot be labeled
refactoring or may be it should be labeld as design refactoring as opposed
to code refactoring.
Ideally, development staff need to allocate a few days or a week
quarterly to address the design and architecture issues and adapt its
design with emerging needs of the customers. You can call it a geek week
and spending a week quarlterly will be a lot effective than rewriting the
On the second part, when to use refactoring I find that most agile
methodologies encourage speedy delivery of the software and
often this gives the impression to move ahead with minimal design or
architecture and refactor a we proceed. Though, I find that architecture
needs to be continuously evolve based on needs, however to start with
no architecture or very minimal one is recipe for rework and waste of time.
Such redesign (or as some people call “refactoring”) is not free, for example
it may require changing the interfaces, switching from RPC based
architecture to messaging based. For a sizeable project, it make sense to
spend a few weeks to nail down immediate and emerging needs of
the application so that even if the software is not able to handle
future needs, it is able to do so in future. One thing that can make a
big difference is having an experienced architect who has build similar
systems before and understands the business domain of the application.
The idea of initial architecture is to have capability to handle future
requirements even when those features are not implemented.
Most of the corporate culture encourages heroism, where dedication or value of employees is measured by how much time evenings or weekend they spend at work. This largely effect how employees are treated by management or promoted. Many such environment also encourage incompetence. For example, if you do a sloppy job at work leading to buggy product or software and then spend nights and weekends to fix them you are lauded and recognized as a dedicated worker. However, if you finish your job within schedule and without any problems and leave your work at time then your dedication is questioned. Most companies don’t realize that when your employees are spending 13-14 hours a day they find ways to do their other personal tasks such as making private calls, dropping cleaning, etc. Nevertheless, it is corporate culture that rewards people who make heroic effort to make up for their incompetence.
Despite a few law suits filed by IT companies such as EA, most companies expect IT (and non-IT) staff to work more than 40-hours per week. As payroll laws exempt IT folks from overtime, it is very hard to do anything about it. There are still effects of the dot bomb and most of the jobs have not returned or have gone to offshore. All this has given companies free reign to treat their IT employees however they want. I have seen companies where despite the fact that people are working 70-80 hours a week, when they asked for raise they were told, “You should be thankful for having a job.” There are plenty of companies who think the only way they can compete with offshore is to match sweatshop environment of offshoring and put their employees with 14 hours a day with 6-7 days a week.