E

In an earlier post I'd lamented about the problems in managing requirements, this post probably reads as a prequel to that one. What are the real problems when it comes to requirements analysis? Meryl K. Evans of the lockergnome identifies 5 specific issues:

1. Customers Don’t Know What They Want
2. Requirements Change During the Project
3. Timeline Trouble
4. Communication Gaps
5. Customer Organization Politics

As a IT professional, I've often found myself at a loss when I've had to explain my job concisely. Usually following the informal pleasantries, including hellos, name exchanges and handshakes is the dreaded "So, what do you do?" Um' I'm an IT professional. Okay, but what do you do? I um.. develop software. Develop software? Well.. I do requirements analysis, design, architect, develop, document, test and deploy software applications based on customer needs, while working with various vendors and integrating with other applications and co-ordinating activities with offshore team members. Huh? I write code. oh! By this time, the pleasantries have ceased to be that, and the other person either looks at you and your family pitifully or warily. The truth is that the software developer of today is expected to perform all these roles. Internet.com, has tried to break down the software development roles as they exist today. Software development, the paper observes, is done differently at every organization, and recognizes that the process that one organization or person uses to develop software may not work perfectly in all circumstances. While environments will change and with that the process that are being adhered would be adapted either marginally or dramatically.. however the multiple and multi-faceted practitioners of the fine art of software engineering remain largely the same - for the requirements are the same - There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. Although each of these processes may change to some extent based on the programming models and tools being used, fundamentally there are some roles, which every process has in one form or another. One person may be filling all the roles or a handful of the roles, or one very specific role. Despite this there is a need for all of the roles -- each serves a purpose. From Subject Matter Experts, Functional Analysts, Solutions Architect, Development Lead, Developer, Quality Assurance, Deployment (Deploy), Training, Project Manager, to the Development Manager, each role has a set of critical skills required. Download the paper from here. (free registration required)

Software development has come a full circle states Alex Iskold in a scathing, pull-no-punches broadside upon the Waterfall model. Read it here: the future of software development Alex states that arrogance was the main problem with the waterfall model. The arrogance he argues came from the fact that we believed that we could always engineer the perfect system on the first try. 37 years ago, W. W. Royce published a sequential development model, coining what is now known as the waterfall model. This approach applied the insights from mature engineering disciplines (mechanical, civil, etc.) to software. The idea was to construct systems by

1. first gathering requirements,
2. then doing the design,
3. then implementing it,
4. then testing,
5. and finally getting it out the door in one linear sequence.

1. changes were impossible,
2. the development cycle was too long,
3. systems were over engineered and
4. ended up costing a fortune,
5. and often did not work right. ;-)

• Build small and then add on.
• Model the Happy day scenario. Leave the esoteric corner cases for another day, another release.
• You cannot and must not code for *all* the weird and *potential* use case scenarios
• Build pluggable frameworks
• Design to integrate
• Leave the system open, and flexible

• Have Fun
• Focus on Simplicity
• Adapt the code
• Embrace Change
• Get feedback
• Refactor
• Communicate
• Release Often
• Test

• High-quality, passionate software engineers will be in very high demand and will make substantially more money. - Good!!!
• The developers who do not have great programming skills are going to have to look for jobs elsewhere. - hmmm... why are they in this industry in the first place?
• The changes that we are witnessing today in the social software market are going to reach the enterprise level. - SAS? the Web is the computer?
• Software off shoring will make less and less economical sense. - why so? does agile software development going to make the world less flat?
• Computer science is going to remain a highly competitive and prestigious field. - sure hope so.

1. it would not be possible to have synergistic agile teams across the seas and across timezones.
2. Agility would be impeded due the overhead of heavy documentation; people would not understand the business properly otherwise.
3. it is not cost effective to have several delivery dates from offshore

[Originally posted Friday, November 26, 2004 @ Caffeine Kick] While I know that several Terabytes of data have been generated in the online and off-line feud over what's the better, I decided I wanted to join in with my own rant as well. I have several issues with J2EE and Java, at least the way we have it today. I'll talk about one of them here. There are just too many ways of doing any single thing. Take persistence frameworks, application servers, MVC frameworks, testing frameworks.. the list is virtually endless. For each and every thing that I want to do, I have at least two (usually more) options to choose from, each better, faster, lighter, easier, cheaper… xyz-er than the other. While I understand that choice is a good thing, what we have today is definitely an overkill. So much of time and effort expended on ‘deciding’ the ‘appropriate’ ‘stack’ to use… only have that sinking feeling 1-month into development, when an even better, even faster, even lighter, even easier, even cheaper and … even xyz-er, brand new way of working surfaces out of the blue (usually apache / SF or someplace similar) To EJB or not to EJB is usually the first question, then follows a plethora of nerve wracking choices .. Hibernate or Spring, Struts or JSF, XML or Resource Bundles, Weblogic or Websphere… you get the drift. .Net on the other hand is much more straight forward. You have one vendor, who gives you all the damn stuff that you need. You concentrate on the work at hand. In .Net we do this like this, and that like that. Over, Simple, Period, Full Stop. No further unpleasant DAR (Decision Analysis and Resolution documents), no further uneasy CAR (Causal Analysis and Resolution meetings).. No more irritating sales calls from SUN, BEA and IBM pushing their servers through, No more newbies in the organization with a conceited grin of mockery claiming "we could have done it better if we had used that 'other' framework". [Originally posted Friday, November 26, 2004 @ Caffeine Kick] Seriously, almost 3 years later, what has changed?

Nowadays, this question seems to figure at every technical interview that that I been involved with (at either side of the table). What would you choose - Waterfall model or the Iterative approach? The correct answer - it depends. The usual answer - some mumbling about extreme programming (followed barely disguised rant on how one was forced to use it). Classically, in development we use either the Waterfall or the Iterative approach. While the Iterative approach is more adept at accommodating requirements change, the Waterfall model treats changing requirements as the exception. However, this does not preclude either model or approach from accommodating change. In the waterfall mode - There is a long requirements definition and approval phase (the elusive sign off), followed by the subsequent life cycle steps (design / development / testing / deployment), and there is one huge grand ship date (the famed / dreaded go-live date). The requirements are considered sacrosanct post the sign-off and any change is expensive. In the iterative mode - The development cycle is actually a series of sequential and repeated short release cycles. This lends itself to injecting changes to the application without disastrously affecting the bottom line. While the iterative approach may seem the obvious choice; a panacea for all our problems, the choice isn’t really that easy. See Bill Walton’s take on iterative versus waterfall in Computer World.