tag:blogger.com,1999:blog-4080205386526887625.post4873166685965067429..comments2009-03-31T10:20:52.533-06:00Travis Jensenhttp://www.blogger.com/profile/08454148260119349712noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-4080205386526887625.post-65617593883552012812009-03-31T10:20:00.000-06:002009-03-31T10:20:00.000-06:00Sounds like you have not<BR/>done any maintenance for a project<BR/>done by a group of dudes without much of a well known layers/framework. Maintenance for a project like that sucks much more and once you go through that experience you will change your point of view. I would say when<BR/>original developers are out of reach in the project like that then the project is pretty much dead.<BR/><BR/>Personally I hate these frameworks(seems like every month someone comes up with a new one) because of the learning curve, for example the task<BR/>of getting a return value from a stored procedure in IBATIS hooked up to .NET/SQL Server is still a mystery to me after spending 2 hours trying to do that. (while it would take 1 min<BR/> directly using .NET) <BR/><BR/>However I have to say, in most cases I would prefer to dig through implementation of well known framework and less through your custom logic.Gwenhttp://www.blogger.com/profile/03939189564515787413noreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-42370343962901249922009-03-06T17:55:00.000-07:002009-03-06T17:55:00.000-07:00Very good post. Maybe I&#39;m not a good programmer too, but I&#39;m earning money this way for 14 years now, and I know that some colleques share your impression. I know the ugly copy&amp;paste procedural hell as well as the typical modern framework stack hell you describe. I realy like the wonderful ideas in all those frameworks, seperation of concerns in aop and declarative programming but... every additional framework, technology and concept has a cost: <BR/><BR/>1. the cost for writing code for every layer and finding the route. Simple things just need too much time because of this constant cost. <BR/><BR/>2. the learning courve is multiplied.<BR/><BR/>3. the cost for everything that doesn&#39;t fit in the frameworks oppinion about the world.<BR/><BR/>4. from a customers perspective - will it be easier to find experts in 20 years knowing all 10 Languages and 12 Frameworks in your currently redesigned state-of-the-art application than finding a cobol expert today? <BR/><BR/>For DSLs: I tried it for a long time and had to give up finaly. In theory it serves a wonderful clean and compact description of my application without any noise. But the DSL and the generator isn&#39;t for free - in fact all of the dirt is just sweeped under the carpet, and because I have to deal with a more general approach I have to solve much harder problems. And what if I want to combine it with some other domain? Maybe DSL are just suitable for some niches.<BR/><BR/>In my experience handling complexity means:<BR/><BR/>- not doing something<BR/>- using just one or two simple and right abstractions<BR/>- being brave enough to accept dirt<BR/>- reimplement it from time to time<BR/>- knowing some nice tools<BR/><BR/>- throwing away every tool / server / framework / layer that isn&#39;t essentialSorokanhttp://www.earthdawn-wiki.denoreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-92121091991257842082009-02-21T15:18:00.000-07:002009-02-21T15:18:00.000-07:00The new mantra should be "all programmers are below average", reverse grade inflation.<BR/><BR/>The inherent problem is the iterative layering of abstractions. Every organism has junk DNA. Every added abstraction adds to the junk DNA for the system being described. Abstractions are used for us humans to get a grasp at the problem. Anytime we can't figure out the system, we will add an abstraction. If we could remember 1000 things with same clarity as 3 our code would look much different. I think it would look like <I>noise</I>, channel 3.<BR/><BR/>When I look at old code bases and what Travis describes isn't just an issue for <B>enterprise</B> software but all software that has grown <I>large</I> is that domain logic gets diluted across so many lines of code and so many classes that it is <B>incomprehensible</B> to anyone, not just <I>below average</I> programmers. Business logic spread like a thin pate so as to be tasteless.<BR/><BR/>Here is a simple scenario, how about logic that says, "if someone has more the $100 dollars worth of physical goods in their cart we charge them 80% of <B>actual</B> cost to ship those goods via the carrier of their choice." Now how many lines of code does that take to express in your system. And how many places does it have to be checked/called/double checked, etc?<BR/><BR/>I think the use of DSLs (domain specific languages) is a huge step in the right direction. See the podcasts on <A HREF="http://www.se-radio.net/" REL="nofollow">se-radio.net</A>.<BR/><BR/>Funny thing, the top link on se-radio is about MPS a domain specific language generator from Jet Brains!<BR/><BR/>Thanks for the post, I think the message needs to get out and the software world is coming around slowly. It will ebb back towards suckage, but I would like to have <A HREF="http://lesscode.org/" REL="nofollow">lesscode</A> to deal with. Languages on the JVM (clojure, javascript) and the new <A HREF="http://www.infoq.com/articles/java7-module-system" REL="nofollow">module system in java 7</A> are very exciting. As a developer I would love to think in ideas and not shovel <B>klocs</B> around.Sitkahttp://xyke.comnoreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-81147691880381374382009-02-21T07:09:00.000-07:002009-02-21T07:09:00.000-07:00The idea of the "below average" programmers bothers me here because it pollutes this debate.<BR/><BR/>It is very easy to point fingers to the developer, when the topic is on the complexity of the software.<BR/><BR/>I think the initial poster is right in raising the point on the complexity of code and the difficulty to support it.<BR/>And this is true irrespective of the level of the programmer.24shoes+blog@gmail.comhttp://www.blogger.com/profile/05994247603173766106noreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-70151135941813612082009-02-18T14:03:00.000-07:002009-02-18T14:03:00.000-07:00Great post, Travis. It can be very trying to find the exact spot where a defect occurs. It's also worth pointing out that well over <I>half</I> of all developers are "average or below". There's got to be a simpler way, or better tools, or something to address this issue.Bruce Conradhttp://www.blogger.com/profile/16804817525665812167noreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-72922874229470109962009-02-16T14:48:00.000-07:002009-02-16T14:48:00.000-07:00I agree with Travis, but I would also like to point out that in addition to creating unnecessary complexity, many "architect wannabees" grab the latest cool framework and try to jam that into the project so that their resume looks great when they inevitably, usually sooner rather than later, move on to their next job. It is like a sales guy who can't sell anything, except an "architect" who doesn't know how to write code leaves a wake of garbage in his path, whereas a bad sales guy just never sells anything.<BR/><BR/>Java has become the refuge of the erector set brigade. If the erector set doesn't have the part that you want, too freaking bad. Even more startling, that type of approach has not only become acceptable, it has become desirable. That is also why enterprise software SUCKS!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-11476024115037302912009-02-11T06:34:00.000-07:002009-02-11T06:34:00.000-07:00Struts - makes me puke.<BR/><BR/>Try Grails FTW!Dmitriy Kopylenkohttp://www.blogger.com/profile/09103763160500756208noreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-46485135602170221892009-02-10T15:59:00.000-07:002009-02-10T15:59:00.000-07:00I would have to disagree with the other commenter. From the post, I think that main problem is the use of Flex :-) but I know that is just me.<BR/>You can't talk about who is and isn't in the right business - you can't ask people to leave and it's not normally your job to hire/fire peers.<BR/>Finally, having also developed applications for six years; my latest being Spring/Hibernate/Struts, as soon as software approaches a certain level of complexity it should either be more than one piece of software or redesigned.<BR/>The original post is right on.HighTechSamuraihttp://www.blogger.com/profile/00820157398592673682noreply@blogger.comtag:blogger.com,1999:blog-4080205386526887625.post-31766223675276870912009-02-05T07:08:00.000-07:002009-02-05T07:08:00.000-07:00I would have to disagree. Software solving complex problems cannot be simplistic. And having a sound layered architecture is very helpful in the long run for relative ease of maintenance/enhancements. I'm speaking from experience of building layered Spring-based systems for 6+ years now.<BR/><BR/>And I believe that "below average" programmers who always complain that they don't understand something without trying to understand, are in the wrong business. It certainly helps if the organization has passionate senior developers who do help junior programmers to become better developers and make them appreciate sound software architectures of today's complex world.<BR/><BR/>As a side note, take a serious look at Grails http://grails.org which does a good job of reducing some of the complexity in the enterprise Java land.Dmitriy Kopylenkohttp://www.blogger.com/profile/09103763160500756208noreply@blogger.com