Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

* Companies

Cooling down... laying off!

The Internet miracle is now showing a new trick: making jobs disappear at e-consulting companies. Recently MarchFirst said that it would lay off 1000 employees or around 10% of its workforce to save $ 100 million. Razorfish plans to cut with a similar percentage in its employees' ranks. Deep troubles also for iXL that will let go 35% of staff (850 employees) and close seven offices. Finally, Scient will lay off 25% of its work force (460 jobs) and close two offices.

The cause is not that development of Web-based applications is disappearing, although the failure of "" companies has hurt demand, but these companies are also spending a lot of dollars in infrastructure items like fancy offices or salesmen. The flow of consulting fees has to be big enough to cover these costs, which is not currently the case as competition is big in this area. According to Scient CEO, his company was undercut by as much as 40% on some projects by Big Five competitors. Traditional companies are also taking more time to examine their Internets needs.

Rational buys Catapulse

Rational has completed in November the acquisition of Catapulse, a company founded in October 1999 by two Rational's co-founders Paul Levy and Michael Devlin. Rational already owned 35% of Catapulse. This company is specialized in leasing software development tools over the Internet in cooperation with firms like IBM and Loudcloud.

This acquisition is the confirmation that the current trend of application service providers (ASP) over the Net is also spreading in the software development industry.

* In Others' Words

Light structuring

"How do you structure a process as complex as software development without killing it? Without creating that deadly momentum that translates good intentions into a process straitjacket? It is perhaps the fundamental problem of our profession. [...]

In the time since my fateful experience with methodology, I've done a lot of development and visited a lot of development organizations. One thing that's new in the intervening years is the proliferation of companies that sell software commercially and the resulting size of that industry. Software development's mainstream is no longer large companies building systems internally, but smaller companies building systems for sale to other companies and consumers. Not surprisingly, the fierce crucible of market competition has brought changes in the supporting product-development process. And guess what? The vision we had - of a calm, rational development process, a kind of engineering - it's toast. Gone. [...] I don't think I've visited any commercial software companies where the development process is truly calm and rational. [...]

Here are some characteristics of modern software development processes that I'd suggest are pretty representative of strong development organizations.

  • Superstar individuals are the difference between success and failure. Cruise the code and you'll always find disproportionate evidence of a few strong developers - way disproportionate. Said another way, this software thing is a craft, and stellar craftspeople are the key. It's one of the features we complained most about in our methodology days. We used to talks about taking the art out and making the process more scientific. That's looking increasingly like a fantasy we indulged in from within protected internal IT enclaves.
  • Requirements change continuously. We used to talk about nailing down the requirements up front, engaging users in contract they would sign off on upon delivery. In market-facing organizations, there is little time for this. It's a fact of business life that important stuff comes up later, and a process that deflects late changes risk irrelevancy.
  • Lots of things happen in parallel. We used to argue that an error caught in testing was a lot more expensive that an error caught much earlier in, say, requirements definitions. In the massively parallel development processes of many new organizations, it's challenging to say what earlier means, except in general sense. The best development organizations have worked on making all changes less costly, and on making development a set of concurrent rather than sequential steps. The build cycle organizes development. In a sense, the build cycle has collapsed the stages of our old methodology into a tightly compressed timeframe - sometimes a day (or less). What we're doing is not sequential with support for iteration, like my old version of methodology; rather it's fundamentally iterative.

One very successful company I know deliberately eschews formal process and even organizational structure. They hire the smartest developers they can find, organize them into very small teams, and then get out of the way, holding individual developers responsible for the quality of their products (as determined by automated testing routines). Rather than assemble requirements documents, they use supertalented developers to build overnight prototypes. Even if the prototype is miles off from what the customers want, the resulting customer reaction is far more informative than most conscientiously constructed document, and the developer learns what's needed a whole more quickly. The development VP there once wrote operating systems at a big company and knows the shortcomings of methodology-intensive ways.

These New Age companies structure their processes only to the extent that it works. If something doesn't work, they either stop doing it or lose in the marketplace. What they evolve in the way of process does sometimes seem to fit with more traditional notions of software methodology. Rapid prototyping is not particularly new. And these companies do adopt more structure as they grow, because they are to some extent overcome by the growing complexity for informal processes (at some point, coordination between different developers gets really hard.) In addition, a lot of what they are doing is simple experimentation, some of which will be rejected eventually. But when it comes to structure and the everpresent need to get new product to market, it's a balancing act - a tension that must be managed. It's not about finding an optimal process that can be designed perfectly enough to solve the problem completely.

In this world, the real phantom menace is the seductive idea that you can construct an optimal, engineeringlike process for developing high-quality software products. It's this idea that gets the ball rolling toward the stultifying "filling in" to which my treasured notion of methodological excellence succumbed so long ago. It's what threatens to steal the vitality from agile development organizations, to turn them into stodgy corporate IT departments clones. A big part of the problem is with our analogies - the patterns to which we aspire. Is software development really like manufacturing? Is it really like engineering? Maybe we need some new patterns. [...]

What then should we do? [...] One of the best things we can do is try to learn how other young, market-facing, rapidly growing companies are doing things. Often these companies are not encumbered by standard patterns and language, simply because they don't have a history of using them. Many are doing a lot of experimenting, which makes it hard to separate what they'll keep doing from what they're just trying and will eventually stop. Also, some of what they're doing might not be relevant to you because of differences in your situation. But plenty nuggets of goodness are there to be had."

Source: Robert D. Austin, "The Phantom Menace", IEEE Software, September-November 1999.

This article pose important questions on why and how to implement process-like attitudes in a software development organization. But if all developers and users were geniuses, there will be no problems in our profession. Oops, I forgot managers! The question is how to insert in software product some common and long-term values when the many of the software "craftspeople" are individual and short-term oriented. The requested qualities of software project results are not similar one year after its completion.

November 2022
October 2022
September 2022
August 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
November 2009
October 2009
August 2009
May 2009
April 2009
February 2009
January 2009
November 2008
October 2008
August 2008
May 2008
April 2008
February 2008
January 2008
November 2007
October 2007
August 2007
May 2007
April 2007
February 2007
January 2007
November 2006
October 2006
August 2006
May 2006
April 2006
February 2006
January 2006
November 2005
October 2005
August 2005
May 2005
April 2005
February 2005
January 2005
November 2004
October 2004
August 2004
May 2004
April 2004
February 2004
January 2004
November 2003
October 2003
August 2003
May 2003
April 2003
February 2003
January 2003
November 2002
October 2002
May 2002
April 2002
February 2002
January 2002
November 2001
October 2001
May 2001
April 2001
February 2001
January 2001
Winter 2000
Fall 2000

Methods & Tools
is supported by

Software Testing

The Scrum Expert