Keith Harrison-Broninski wrote: > Apps, John wrote: >> Great piece! The only comment I would add is that we need to >> concentrate more on getting problems solved --solutions written-- that >> we do on building and using wonderful IDEs, frameworks and so forth. >> It is my opinion that we in IT still write way too much code, not >> spending enough time solving the 'real world' problems, many of which >> have already been solved using code up to 40 years old. >> Regards, john >> Andrew S. Townley wrote: >>> I do believe that frameworks can increase the productivity of >>> development teams, and I do think that in some cases you can achieve >>> componentized software within a set of constraints, but what I see >>> across nearly every vendor is how pervasive the "pay no attention to the >>> man behind the curtain" attitude is becoming. This really troubles me. >>> >>> While we are lowing the barriers to entry by making software development >>> more accessible with rich frameworks and IDEs, I don't see a >>> corresponding growth in the knowledge and understanding required to >>> apply them effectively. Just because the solution works, doesn't mean >>> that it is effective. As an industry, I think we're focusing more and >>> more on short-term thinking and speed of delivery than we are on trying >>> to really teach people what they need to know to build better software. >>> Sooner or later, I'm afraid that it'll turn around and bite us in the >>> butt. > Thank you for these responses. I agree with both of you in terms of the > problems you identify. But I do not agree with either of your > conclusions! Let me explain ... > > What is happening to IT, quite gradually until recently, is that it is > changing from an amateur to a professional practice. Of course there > have been professional IT staff since the 1960s, but until relatively > recently most of them were not educated in IT - they came from all sorts > of disciplines, including the arts and humanities. And the approach > most such people took to IT was extremely varied, and often governed by > personal predilections as much as by breadth and depth of industry > knowledge. > > Now, it's not a bad thing to have such people around. To the contrary, > in areas such as user interaction design they are essential. And I > myself had to choose at University which route to follow, so I know from > experience that there is no clear-cut division in mindset. However, in > general, IT is becoming so complex these days that it's no longer > acceptable to fudge together solutions - what we need are engineering > practices, followed consistently. > > So, following this train of thought, how do engineers work? What they > *don't* do, is re-evaluate the foundations of their profession every > time they design a bridge. Except for the very few most brilliant > leading lights in every generation, most engineers draw from a small > number of tried-and-tested approaches to carry out their work, whatever > the precise nature of each piece of work may be. And this is what I > think needs to happen, and is happening, in IT. > > In other words, not only do we not have the time to understand the basis > of every framework, but such efforts are misguided. What we should be > doing is going forwards by leveraging the advances of our predecessors, > not continually deciding whether or not they got it right. To try and > do so in fact combines several failures of duty - including in > particular the arrogance to think your employer wishes you to spend your > time deciding whether you personally approve of how > Eclipse/Spring/J2EE/etc were designed, rather than getting on and > delivering the solution they asked you for. > > Now, I know I'm coming on strong here. But I really think it is beyond > time for the IT industry to grow up. We call ourselves "architects". > Well, let's start behaving like architects, then. >
I think it's still unproven just how similar to other engineering practices computing is. Let's say we're building a bridge (a solution): Our customer typically tells us where they want the bridge, what kind of traffic load it needs to cope with (people, vehicles, both etc) and some idea of cost. How much does the customer care about the materials you choose? How much do they care about wind models etc? As an engineer, I will indeed be consulting my encyclopedia of other bridges, design approaches etc but maybe this bridge has some unique aspects that aren't addressed. Now I'll look at whether I can adapt something else or have to it from scratch and my engineering discipline, laws of physics etc allow me to craft a good solution in absence of prior example. How have cars evolved over time? How much of that original model T is in todays cars? Do car engineers spend all their time re-using what they had before or do they sometimes throw out and re-build from scratch? Then there's the length of time it takes to design a new car and deliver it to market or build a new bridge. Are those timescales comparable to computing projects and if they are, are they actually appropriate/realistic? How about the fact that once I deliver a car or bridge, I don't make many changes to it. Does the same happen with software releases? Both of the examples above are actually quite confined in terms of end result. The issue with computing is it tends to be used for _everything_ with each of these things having their own little tweaks (each business just wants that little edge in their systems) which makes mass production practices a little less appropriate. Software engineering is still operating off little history (40 years or so) which surely means we have a lot to learn. Putting on the blinkers and just accepting what has already been done potentially leads to stifled progress because no-one questions any more. And questioning/analysis is a fundamental part of good systems engineering. It's not about whether I personally approve of something, it's about suitability for purpose, it's about how easy it makes the life of my teams to deliver software, it's about how easy the stuff is to evolve and monitor and deploy and frankly, I think we have a long way to go there. There's little in todays systems that's different from more than a decade ago - still multi-tier and more often than not still the 3-tier variety and we still seem to have all the same old problems of complex API's, messy deployment etc. How much progress have we really made? How much further progress will we make if we just accept what came before? No, good architects don't constantly re-evaluate the fundamentals of their profession but they have some pretty good, well proven, long term fundamentals (some of them borrowed from older disciplines such as physics) and arguably we don't. So, sure we'll just use what came before and not question but then no-one can complain when it all turns out the same...... Thanks for the thought provoking post. Best, Dan. > -- > > All the best > Keith > > http://keith.harrison-broninski.info > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
