I just got to know an ex-company of mine has undergone bad times. Based in Amsterdam, apparently it was also not spared of the global economic gloom. My buddies , who are still attached to that company, was informed (informally , as I understand) that the company is undergoing a massive retrenchment exercise for the KL office. My guess is that the whole IT team faced the brunt, due to its operation overheads.
Maybe one day I would like to do a research on the value (intrinsic or extrinsic) of having internal IT department. But for now....
This company holds a dear place in my heart as I happened to be the first Programmer/IT staff to be recruited for development purpose. I was given the task to setup the firewall and all the Linux servers. I really treasured those days sweating out the WatchGuard Firewall policies, IBM Blade Servers and the SunFire Server running on Solaris. I also had the chance to do a RAID cluster among all these servers.
And mostly the company opened up my oppportunity to delve into the world of J2EE, playing around with EJB 2.1 (which I really hated at that time.....and to think about it..I still hate it! I love the later EJB 3.0 though..). I was introduced to JBOSS App servers and JMS Queues.
I really hope that those guys can move on seamlessly through their careers! Hold on guys!
Wednesday, February 25, 2009
Tuesday, February 17, 2009
The 'fall' of the Waterfall Model
The first time I heard of Waterfall Model was when I was an undergrad under the Software Engineering course module. I was like going "wow" when I first become acquainted with this course. Why? It sounded like candy to the green ears of impressionable undergrads.
Fast tracked 7 years down the road, I have seen projects way behind schedule while some are falling apart, bogged down by its own stress. Seasoned programmers will tend to agree that late delivery is inevitable in software development.
To explain the delay, project managers will shrug it off as the 'norm' or maybe some mysterious office-monsters ate all the computers in the office. Team leader or architects will complain lack of resources or maybe the requirement specs are pure bollocks to begin with. Programmers will simply complain that they only have 24 hours per day in their life and they need special privileges as they are 'different' from people in other profession. Sounds familiar?
In the midst of all these chaotic processes to churn out quality codes, the users or clients will drop by and make our lives miserable (as if we are not already!!) by passing a additional set of requirement to our superiors. Behold, the common dreaded word - CHANGES.
Trying to look as if any wrong decisions will stop the sun rising tomorrow, the standard reply will always be "Let me bring this to my architects and their teams and we will reply asap....". Why they even bother to even ask us remains a mystery?
Like it or not, we peons (yes I mean you too!) have no say. The only thing is to curse silently (I prefer to just open up a chat window to a random member in my messenger and do a cyber-scream) whenever we need to re-work our codes. I may hit a chord with those nay-sayers, proclaiming that if our designs are done modularly, there should be minimum refactoring..blah blah blah.
Yeah right! Funny that usually those so called consultants are the very idiots who keep producing theoretical but impractical designs. Or maybe I am simply unlucky! There must be some folks in my corner of the world who can at least produce humanly proper designs.
It took me a while to come to a conclusion, that the current process (Waterfall Model) we keep on slugging simply does not work. It looks nice on paper, but it is so not ready for its archenemy - CHANGES. What?! Even after being first published in 1970, it's still not ready?? After nearly 40 years?!! Gasps!
A simple illustration describing the model.
I will not touch on the description of the model. Just google it and there are vast resources for you to look at. However, what is interesting I found in its Wiki is the statement below.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995),[1] although Royce did not use the term "waterfall" in this article. Ironically, Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development - as a way to criticize a commonly used software practice.
SO WHY THE BLOODY HELL ARE WE STILL USING IT THEN???!!! A nice link about their main drawbacks here.
I will give a quote from Scott Rosenberg's book "Dreaming in Code". What I would like to point out is that by the time a complex project is finished, usually there will be major breakthough or new technologies.
For decades the organization of the typical project followed the "waterfall model." The waterfall approach—the label first surfaced in 1970—divided a project into an orderly sequence of discrete phases, like requirements definition, design, implementation, integration, testing, and deployment. One phase would finish before the next began. This all seemed
logical on paper, but in practice it almost invariably led to delay, confusion, and disaster. Everything took forever, and nothing worked right. Programmers would either sit idle, waiting for the requirements, or give up and start design work and coding before they got the requirements. "Big design up front" led to big delays, and "big-bang integration"—writing major chunks of code separately and then putting them all together near the end of the
project—caused system collapse. By the time the finished product arrived, so much time had passed that the problems the program aimed to solve no longer mattered, and new problems clamored for solutions.
Currently I am in an organization where we are experimenting on Scrums (Agile Methodology).
Its far too premature to provide a clear comparison, however the signs are good, although I find it quite loosely defined and quite prone to abuse. Hopefully I will sit down and write about this after undergoing a fair amount of sprints.
I am not condemning waterfall model actually. Well not too much really. However, I think it's time we review our process and also break from the "follow the crowd" paradigm. Although the model is here to stay and will not fall as I try to overdramatize in this blog title, I have high doubts (I may be proved wrong) and I still question any organization that adopts it, other than the fact it produces nice eye-candy documentation.
Forgive the pun as I enjoy this...Waterfall has fallen!
Fast tracked 7 years down the road, I have seen projects way behind schedule while some are falling apart, bogged down by its own stress. Seasoned programmers will tend to agree that late delivery is inevitable in software development.
To explain the delay, project managers will shrug it off as the 'norm' or maybe some mysterious office-monsters ate all the computers in the office. Team leader or architects will complain lack of resources or maybe the requirement specs are pure bollocks to begin with. Programmers will simply complain that they only have 24 hours per day in their life and they need special privileges as they are 'different' from people in other profession. Sounds familiar?
In the midst of all these chaotic processes to churn out quality codes, the users or clients will drop by and make our lives miserable (as if we are not already!!) by passing a additional set of requirement to our superiors. Behold, the common dreaded word - CHANGES.
Trying to look as if any wrong decisions will stop the sun rising tomorrow, the standard reply will always be "Let me bring this to my architects and their teams and we will reply asap....". Why they even bother to even ask us remains a mystery?
- This is an excellent money-making opportunity for the organization. Every changes will incur additional manhour sweats (ours!), which will obviously mean more bloated invoices for the morons...oops..clients.
- Our schedule will always be delayed. What a good way to justify that the delivery need to be extended due to such changes.
- Customers are always right. Even if they claim the sun is a square cheese up in the sky, who are we to deny them.
- Or maybe we are simply damn cursed to have a splendid boss who have perverse pleasure in making us work through the weekends.
Like it or not, we peons (yes I mean you too!) have no say. The only thing is to curse silently (I prefer to just open up a chat window to a random member in my messenger and do a cyber-scream) whenever we need to re-work our codes. I may hit a chord with those nay-sayers, proclaiming that if our designs are done modularly, there should be minimum refactoring..blah blah blah.
Yeah right! Funny that usually those so called consultants are the very idiots who keep producing theoretical but impractical designs. Or maybe I am simply unlucky! There must be some folks in my corner of the world who can at least produce humanly proper designs.
It took me a while to come to a conclusion, that the current process (Waterfall Model) we keep on slugging simply does not work. It looks nice on paper, but it is so not ready for its archenemy - CHANGES. What?! Even after being first published in 1970, it's still not ready?? After nearly 40 years?!! Gasps!
A simple illustration describing the model.
I will not touch on the description of the model. Just google it and there are vast resources for you to look at. However, what is interesting I found in its Wiki is the statement below.The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995),[1] although Royce did not use the term "waterfall" in this article. Ironically, Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development - as a way to criticize a commonly used software practice.
SO WHY THE BLOODY HELL ARE WE STILL USING IT THEN???!!! A nice link about their main drawbacks here.
I will give a quote from Scott Rosenberg's book "Dreaming in Code". What I would like to point out is that by the time a complex project is finished, usually there will be major breakthough or new technologies.
For decades the organization of the typical project followed the "waterfall model." The waterfall approach—the label first surfaced in 1970—divided a project into an orderly sequence of discrete phases, like requirements definition, design, implementation, integration, testing, and deployment. One phase would finish before the next began. This all seemed
logical on paper, but in practice it almost invariably led to delay, confusion, and disaster. Everything took forever, and nothing worked right. Programmers would either sit idle, waiting for the requirements, or give up and start design work and coding before they got the requirements. "Big design up front" led to big delays, and "big-bang integration"—writing major chunks of code separately and then putting them all together near the end of the
project—caused system collapse. By the time the finished product arrived, so much time had passed that the problems the program aimed to solve no longer mattered, and new problems clamored for solutions.
Currently I am in an organization where we are experimenting on Scrums (Agile Methodology).
Its far too premature to provide a clear comparison, however the signs are good, although I find it quite loosely defined and quite prone to abuse. Hopefully I will sit down and write about this after undergoing a fair amount of sprints.
I am not condemning waterfall model actually. Well not too much really. However, I think it's time we review our process and also break from the "follow the crowd" paradigm. Although the model is here to stay and will not fall as I try to overdramatize in this blog title, I have high doubts (I may be proved wrong) and I still question any organization that adopts it, other than the fact it produces nice eye-candy documentation.
Forgive the pun as I enjoy this...Waterfall has fallen!
Monday, February 16, 2009
Welcome to the Moose Corner!
After years of slogging and perspiration doing software development, I have decided to create my own corner (blog) to publish some findings and also to discuss some of the interesting issues a software developer usually come across.
It's a general conception that a software developer (regardles whether he is a software architect, team leader or even a humble coder) have to learn and understand basic software skills, methodologies, process and sometimes even design patterns.
However, how many times have we come across situations where its not stated in the textbook, or maybe sometimes what stated in the textbooks do not seem to be the most ideal of solution.
I hope to publish and discuss some of these so called grey areas or maybe get some opinions or 2!
And lastly why 'toffeemoose'??
Well I support one of the best club (Everton), nicknamed Toffee and Moose is the nickname I gotten as a coder.
Perhaps one day I will even publish the whole story if anybody is interested.
It's a general conception that a software developer (regardles whether he is a software architect, team leader or even a humble coder) have to learn and understand basic software skills, methodologies, process and sometimes even design patterns.
However, how many times have we come across situations where its not stated in the textbook, or maybe sometimes what stated in the textbooks do not seem to be the most ideal of solution.
I hope to publish and discuss some of these so called grey areas or maybe get some opinions or 2!
And lastly why 'toffeemoose'??
Well I support one of the best club (Everton), nicknamed Toffee and Moose is the nickname I gotten as a coder.
Perhaps one day I will even publish the whole story if anybody is interested.
Subscribe to:
Posts (Atom)