- From: Andrew S. Townley <andrew.townley@bearingpoint.com>
- Date: Fri, 07 Apr 2006 11:26:30 +0100
- To: adasal <adam.saltiel@gmail.com>
- Cc: semantic-web@w3.org
Hi Adam, On Thu, 2006-04-06 at 23:48, adasal wrote: > I had thought that these things may go in cycles, possibly fashion, > possibly economic influence. and: > It seems there has been a drift away from design methodologies, I know > I have made a conscious decision in this direction, but think about > the use of POJOs, test driven development and so forth in Java. > Moreover, in the end, it is the code that counts, that is what brings > the money in for a company, so programmers are trained to think of > being productive as the production of code artifacts. That there isn't > a clear separation between architects, designers and builders is > probably a mark of the immaturity of the software industryas well, I > don't know. Be careful here. Some of what you've actually described (test-driven development, for example) *are* parts of methodologies. As you say, these things are cyclical, but I think it's worth noting that (as you mentioned in another reply), some of the research Microsoft is sinking money into is around trying to reverse the current cycle somewhat and reinforce the good things we've learned as an industry through the development of Agile methodologies while at the same time trying to move things back to a little more structure. It's a tough balance to strike, but there are those that believe it can be done successfully (myself included). You also mention a point about programmers being trained to think of code artifacts being directly proportional to revenue generation. This is true, but only to a point. Remember your software economics (Boehm); there are always trade-offs involved. The only way that focus on code delivery and code delivery alone can possibly make sense (in a naive way) is in short-term financial terms for a license and support-based software company. The economics come in when you figure the total cost of ownership of a piece of software through the entire lifecycle. Even in the license-based model, if poor quality software is delivered at high costs, the company may make additional revenue from consulting and support engagements. However, unless they do something about the quality of the software overall, they will eventually lose customers (killing the goose that lays the golden eggs). Microsoft* learned this lesson about security (eventually), because people chose other platforms and the press an Internet articles were eroding their customers' confidence. Eventually, license-based software companies will need to consider the same sort of decisions if they want to stay in business. If you're not license based and it's an internal IT project, this is a lot more relevant to your overall operational budget. You are only hurting your own bottom line, even if you may make the project delivery dates. There are some strategic reasons you might choose to do this, but if you do, you'd better have a plan on how to get out of it in the near future. Of course, the trade-offs must be made based on the type and scope of the project involved. Prototypes, demos, proofs-of-concept, etc. have different rules. For some of these considerations, see [1] & [2], but the overall point is that you (or the organization that pays you) will eventually have to live with the consequences of the choices they make. Don't get me wrong, I'm not saying that Agile is bad or any other particular methodology is good, but I am saying that what I see in the industry right now is a lot of people who don't tend to have an awareness of how the pieces fit together (and I'm not trying to pick on you, Adam :). This is a *bad thing* because it hurts the entire industry. So, really, I'm just advising you (and anyone else) to be careful and think about the trade-offs you make when you're writing code. Cheers, ast * Those who know me will be amazed that I actually used Microsoft twice in one email in a positive light. :) Personally, I'm a little amazed as well, but, in some areas, they have made conscious efforts to fix some of their faults, so you have to give them credit where credit it due. [1] http://www.joelonsoftware.com/printerFriendly/articles/SetYourPriorities.html [2] http://www.joelonsoftware.com/printerFriendly/articles/PickingShipDate.html -- Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at InfoSeCon 2006. For more information, see www.infosecon.org. *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ***************************************************************************************************
Received on Friday, 7 April 2006 10:36:41 UTC