Why you need architects
It’s a bit older, but … Why you need architects.
Through Mike Walker’s blog, I just know that Microsoft has announced a new initiative, called “Banking Integration Factory“, that provides prescriptive architecture guidance, tools and reference implementations aimed at achieving consistency in banking integration. At the MSDN Banking Industry Center there are some articles describing it. It’s worth reading.
Martin Fowler is talking about how to improve the productivity of software developers:
An answer I’ve given regularly for many years now, and one that applies to almost anyone who uses a computer, is give them a bigger screen.
These days I say that everyone should have at least two 20 inch screens.
You need more arguments, see the 30-inch Apple Cinema HD Display study, by Pfeiffer Consulting and sponsored by Apple, which states that providing employees with 30-in. computer monitors can boost worker productivity at companies where 17- or 19-in. monitors are typically used (BTW, this study was fiercely criticized by Jacob Nielsen in a recent post titled Productivity and Screen Size).
M.I.T. Technology Review had a very interesting interview with Bjarne Stroustrup about C++ and the quality of software today. The interview, The Problem with Programming, has engendered a controversial debate, so they decided to publish a second part, More Trouble with Programming.
Here are some excerpts:
About why is most software so bad:
I think the real problem is that “we” (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but–so often–it’s not enough.
About CS education:
The idea of programming as a semiskilled task, practiced by people with a few months’ training, is dangerous. We wouldn’t tolerate plumbers or accountants that poorly educated. We don’t have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
About tools:
Obviously, we don’t want our tools–including our programming languages–to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals–not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let’s not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
About AOP:
I hope you didn’t put too much money on it! I don’t see aspect-oriented programming escaping the “academic ghetto” any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it’s not clear how many applications significantly benefit from its use. Also, with AO, it appears difficult to integrate the necessary tools into an industrial-scale programming environment.
(Via Slashdot)
A new article at BEA dev2dev has been published about Exploring Ajax Runtime Offerings. This article tries to provide some guidance in exploring the space, the tools for understanding how frameworks compare, and a view of what some of the trends are for the current Ajax frameworks.