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 "dot.com" 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.
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |