The Artima Developer Community
Sponsored Link

Weblogs Forum
Where Did All the Beautiful Code Go?

97 replies on 7 pages. Most recent reply: Apr 15, 2006 12:55 AM by Andy Dent

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 97 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 1:51 PM
Reply to this message Reply
Advertisement
> If there are common issues between large projects and
> small projects, why would you choose to study those common
> issues in large projects where there are additional
> (dominant) problems, rather than studying them in small
> projects where they stand alone?

Now you are implying that small projects have one problem. I'm can only bat away rhetoric for so long before it gets really boring.

It's my contention that technical debt is one of the dominant issue with the Vista project and it is backed up by many references that you can find on Google if you care to look.

> Happily, Capers Jones has published widely, for those who
> are willing to learn from others experience.

Excellent. That means you can let his published works speak for him instead of trying to channel him with your dubious interpretations.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 2:55 PM
Reply to this message Reply
> It's my contention that technical debt is one of the
> dominant issue with the Vista project and it is backed up
> by many references that you can find on Google if you care
> to look.

I think the dominant issue with Vista is backward compatibility. Linux or various Apple OS's don't carry as much baggage, but no ancestor of them ever ran on a 8088 with 16K of RAM or had so many widely-used applications depending on legacy behavior.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 3:36 PM
Reply to this message Reply
> I think the dominant issue with Vista is backward
> compatibility. Linux or various Apple OS's don't carry as
> much baggage,

My understanding is that they cannot keep IE from crashing constantly. It doesn't seem to me that that is a backwards compatibility issue.

I do agree that their backwards compatibility is an issue. But it seems to me that the reason it is such a struggle is that the issue was never mangaged in a clean way. Backwards compatibility can be managed cleanly and you can write new code that is backward compatible. Of course, that's not the easy way to do it and we are back to technical debt.

> but no ancestor of them ever ran on a 8088
> with 16K of RAM or had so many widely-used applications
> depending on legacy behavior.

I can't seem to find the hardware reuqirements (I thought they had been released) but I'm going to go out on a limb and say that the above will not be supported.

Maybe it is too hard to know exactly what is going on. But according to what they have sated their process is and what alledged MS bloggers are complaining about, I get the feeling that they have 50 million lines of spaghetti code. How else do end up taking two years of 100s of developers work and scrapping it? Maybe there's something else going on but I think it's quacking.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 4:03 PM
Reply to this message Reply
> But it seems to me that the reason it is such a struggle
> e is that the issue was never mangaged in a clean way.
> Backwards compatibility can be managed cleanly and you
> u can write new code that is backward compatible. Of
> course, that's not the easy way to do it and we are back
> to technical debt.

Well, I'm sure that in small applications with a relatively short history and few dependencies backwards compatibility can be managed cleanly. Do you have any examples of that being accomplished for large applications with a long history and lots of dependencies?


> I can't seem to find the hardware reuqirements (I thought
> they had been released) but I'm going to go out on a limb
> and say that the above will not be supported.
>

The point is that required trade-offs made in the 8088 era impact the required behavior in the present.


> Maybe it is too hard to know exactly what is going on.
> But according to what they have sated their process is
> s and what alledged MS bloggers are complaining about, I
> get the feeling that they have 50 million lines of
> spaghetti code. How else do end up taking two years of
> 100s of developers work and scrapping it? Maybe there's
> something else going on but I think it's quacking.

Do you really believe that MS is writing spaqhetti code? That somehow programmers hired by MS are below average and don't understand good design like everybody else? I think it's the nature of what they are trying to accomplish that's giving them trouble.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 4:57 PM
Reply to this message Reply
> > But it seems to me that the reason it is such a
> struggle
> > e is that the issue was never mangaged in a clean way.
> > Backwards compatibility can be managed cleanly and you
> > u can write new code that is backward compatible. Of
> > course, that's not the easy way to do it and we are
> back
> > to technical debt.
>
> Well, I'm sure that in small applications with a
> relatively short history and few dependencies backwards
> compatibility can be managed cleanly. Do you have any
> examples of that being accomplished for large applications
> with a long history and lots of dependencies?

No I suppose I don't. In fact I've never really seen a clean code base that had more than one developer.

However, I don't think it's impossible, I think it's prohibitively expensive or percieved to be so.

In any event, if you seem to be saying that windows idea of deep backwards compatiblity is basically doomed to failure. Maybe not now but in the future.

> > I can't seem to find the hardware reuqirements (I
> thought
> > they had been released) but I'm going to go out on a
> limb
> > and say that the above will not be supported.
> >
>
> The point is that required trade-offs made in the 8088 era
> impact the required behavior in the present.

Yes but I don't see how that leads to an inability to produce a stable system. A hobbled system yes, but not unstable. I'm open to your ideas, though.

> > Maybe it is too hard to know exactly what is going on.
> > But according to what they have sated their process is
> > s and what alledged MS bloggers are complaining about,
> I
> > get the feeling that they have 50 million lines of
> > spaghetti code. How else do end up taking two years of
> > 100s of developers work and scrapping it? Maybe
> there's
> > something else going on but I think it's quacking.
>
> Do you really believe that MS is writing spaqhetti code?

Yes, absolutely.

> That somehow programmers hired by MS are below average

No. I think they are mostly about average.

> and
> don't understand good design like everybody else?

Well, I don't think a lot of people understand good design. But no. I think they understand it but like most developers, they have to work with what is there. I doubt very highly that they have 50 million lines of pristine code written over several decades. The size of the Linux kernel is about 5 million, from what I understand. Of course, windows has a lot more in it that just the kernel, which is really another problem for them, I would think. By not having clean abstraction layers between the apps and the os, they've increased the dependencies greatly.

> I think
> it's the nature of what they are trying to accomplish
> that's giving them trouble.

It seems to me that they have dropped a lot of the really heavy technical changes such as WinFS.

In any event, even if you are right, the end result is the same. They are struggling. In our capitalist system, having a hard climb doesn't get you points. It the results (theoretically.)

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 5:04 PM
Reply to this message Reply
I think the original post's key point was not so much code quality, but that writing code that's hard for another programmer to understand can lead to a slide in the overall quality of the project.

This's actually easy to imagine. Considering language, few men have ever mastered the English language more than Shakespeare did. No one can deny that Shakespeare's writings exude quality, which is close to the highest quality experience one can have with any language. (We could substitute any other great writer or poet here, such as Hemingway or Verlaine.)

But imagine what would happen if Shakespare were your co-worker and he would send you his email messages in his own Shakespearian style, expecting a reply. Clearly, you could sit before responding to each message, chiseling the style of your response for a couple of hours. Even then, it's likely that someone reading the email thread as a whole could claim that your responses degraded the quality of the correspondance.

The point of the post, I think, is that writing code that's idiosynchratic, or even one that's too abstract, will cause someone else to not spend too much time trying to understand it, let alone write in the idioms of that 'beautiful' code. Instead, that person will just think, "Hmmm, this works, so I'd better not touch it. But I just insert my code here..."

What does that imply? For one, each project will have to decide the level of abstractions used. If such abstractions are too high, and require too much context to understand, then people will likely bypass them, lowering the overall code quality.

As others have pointed this out, quality is in the eye of the beholder. Would you consider a Shakespearian co-worker's email style high quality or just pompous and, possibly, counterprodutive?

One more point: Some devices that are supposed to improve code quality on occasion might, in fact, lower quality. For instance, I worked years ago an a Web site/enterprise app using Perl. I was rather experienced, and tended to repeat code all over the place. While I now frown upon that practice, I also recall that that code base actually worked really well, and was also easy to maintain: Since almost everything happening at a given place could be understood just by looking at a screenful of code, bugs were easy to fix and find. The low level of abstraction in the code made it easy to work with that code. I could get right to what I wanted to do or where I wanted to fix a bug, and be done with it.

By not having to hold a large context in the mind, working on that code was not mentally exhausting, and thus I could do productive work on that code base for many hours at a time. By contrast, when one has to keep in mind several layers of abstraction, configuration files, and such, much more is required of the mind, which leads to people becoming fatigued sooner, possibly leading to lower overall productivity. I think the saying "too clever by half" sort of describes this well.

> The sequence of events Hohpe outlined begins with the
> developer writing code that is serviceable for the
> application – it runs okay – but the code itself is
> idiosyncratic and hard for another programmer to
> understand. The along comes a programmer doing maintenance
> a year after the application goes live. The code appears
> to be a convoluted mishmash.
> </p>

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 5:07 PM
Reply to this message Reply
> > If there are common issues between large projects and
> > small projects, why would you choose to study those
> > common issues in large projects where there are
> > additional (dominant) problems, rather than studying
> > them in small projects where they stand alone?
>
> Now you are implying that small projects have one problem.

Not true: "issues" plural, "problems" plural.

You have used a strawman argument to avoid answering the question - evidently you find quarreling more interesting than I do.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 5:39 PM
Reply to this message Reply
> > > If there are common issues between large projects and
> > > small projects, why would you choose to study those
> > > common issues in large projects where there are
> > > additional (dominant) problems, rather than studying
> > > them in small projects where they stand alone?
> >
> > Now you are implying that small projects have one
> problem.
>
> Not true: "issues" plural, "problems" plural.

We are talking about one issue in this thread. I don't know what issues you are referring to and what project I should be looking at to fit these unstated issues. We've already stated different types of projects have different sets of issues. That says nothing about which ones are more relevant to this discussion.

> You have used a strawman argument to avoid answering the
> question

This is from the person who states he is using the 'appeal to authority' fallacy in his argument. Although, I think it was really another fallacy, one that I don't know the name for. In short, taking someone else's statement and applying a thick layer of interpretation without any references to back up a bit of it.

> - evidently you find quarreling more interesting
> than I do.

No I find rehtorical arguments about how what you think someone else, who is claimed to be an expert, meant in an out of context sentence invalidates my points to be extremely rude. Don't tell me the Capers, Einstein, or Confuscious says I'm wrong or that your dad is bigger than my dad. If Capers thinks I'm wrong and cares he'll have to tell me himself. Argue your own points.

If you want to discuss the issue discuss it. If you have something specific (i.e. not 'they are different') to point out about big project, do so. If you have a refence to point me to that describes why it doesn't make sense to disuss big projects in this context, do so. Leave the debate team tactics at grade school.

I don't see how a small project is more relevant than a large one in the context of this thread. And no, 'Capers says so' isn't compelling. Your argument is that big projects are different than small projects. Thank you for that amazing observation.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 5:49 PM
Reply to this message Reply
> One more point: Some devices that are supposed to improve
> code quality on occasion might, in fact, lower quality.
> For instance, I worked years ago an a Web site/enterprise
> app using Perl. I was rather experienced, and tended to
> repeat code all over the place. While I now frown upon
> that practice, I also recall that that code base actually
> worked really well, and was also easy to maintain: Since
> almost everything happening at a given place could be
> understood just by looking at a screenful of code, bugs
> were easy to fix and find. The low level of abstraction in
> the code made it easy to work with that code. I could get
> right to what I wanted to do or where I wanted to fix a
> bug, and be done with it.

What about when the code that was pasted into many different places needs to change?

Having spent many a week modifying code that was repeated over and over again, I can say that it was definitely not easy to maintain.

But I think I agree with your general point here. Striking right the balance is an art and not an easy one.

To be honest, I'm a little cynical about the prospects of a project full of beautiful code. There are very few times that I open up someone else's source and feel good about what I see. The same it true for a lot of my own code. It's entropy. A lot more states are disordered than ordered.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 6:52 PM
Reply to this message Reply
> > If there are common issues between large projects and
> > small projects, why would you choose to study those
> > common issues in large projects where there are
> > additional (dominant) problems, rather than studying
> > them in small projects where they stand alone?

> Now you are implying that small projects have one
> problem.
>
> > Not true: "issues" plural, "problems" plural.
>
> We are talking about one issue in this thread. I don't
> know what issues you are referring to and what project I
> should be looking at to fit these unstated issues...
-snip-

The very same "common issues" you wrote about Mar 29, 1:06 PM.

> > You have used a strawman argument to avoid answering
> > the question
>
> This is from the person who states he is using the 'appeal
> to authority' fallacy in his argument.

Once more you have chosen to avoid the question.
(Appeal to relevant authority is not a fallacy.)

-snip-
> I don't see how a small project is more relevant than a
> large one in the context of this thread. And no, 'Capers
> says so' isn't compelling. Your argument is that big
> projects are different than small projects. Thank you for
> that amazing observation.

Another strawman distortion.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 6:55 PM
Reply to this message Reply
> > app using Perl. I was rather experienced, and tended to

Oops, I guess I wanted to say inexperienced.

> > repeat code all over the place. While I now frown upon
> > that practice, I also recall that that code base
> actually
> > worked really well, and was also easy to maintain:
> Since
> > almost everything happening at a given place could be
> > understood just by looking at a screenful of code, bugs
> > were easy to fix and find. The low level of abstraction
> in
> > the code made it easy to work with that code. I could
> get
> > right to what I wanted to do or where I wanted to fix a
> > bug, and be done with it.
>
> What about when the code that was pasted into many
> different places needs to change?

Well, the point is that there was no code that was in many places, because the system consisted of hundreds of little scripts that each did something immediately obvious. The only that might have changed system-wide was perhaps database configuration, but that, again, was immediately clear how to do.

I guess I'm just saying that having a high level of abstraction might often seem the intellectually superior thing to do, and often is - but not always. I was not talking about duplicating code in the style of cut-and-paste, but rather to have a somewhat flat hierarchy of layers instead of lots of indirection, and to write code that directly does what it's supposed to do.

For instance, in Swing code, people initially attached action handlers to widgets and performed the needed actions right in that code, such as:


jbutton.addActionListener() {
public void actionPerformed(ActionEvent e) {
// do something important here.
}
}


Then this was considered bad form, because you're mixing business logic with presentation. So if you decided to perform that really important thing apart from a JButton, you could not reuse this action. Folks then decided to define Action objects apart from the UI widgets, add those actions to action maps, and, attach the needed actions to the widgets. Now, this means you have to have an action map, you have to configure it, etc, etc. Modular? Yes. Easy to understand? No way. If your button doesn't do what it's supposed to do, you have to look in 3-4 files just to get to do the code you're interested in. One could quote many, many such examples.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 7:07 PM
Reply to this message Reply
Peter Hickman: "Coding as guerrilla warfare is the only attitude that will get any results in the companies that I have worked for."
Same experience. It simply doesn't help to point out, to suggest, to argue. No project manager will allow time for necessary code cleanup. What's in it for him? What can he bill the customer? The only way I know of producing quality code is to simply do it, without asking. It can make you enemies, though.

Vincent O'Sullivan: "There is one code quality tool whose use used to be widespread but which pretty died out (in my experience) about ten years ago. It requires no installation and provides an ideal mechanism for disseminating good practice across a team. It's the code walk-through."

Again, I second. What I experience is a reluctance to engage in any discussion about code quality, about style, a reluctance to exchange and learn from each other. Instead, we now have sterile code convention documents, sometimes so silly as to prescribe in detail where a blank can be entered with impunity. I completely disagree with those who say that automated "code quality tools" can help ensure code quality. Sigh. Same for unit tests. Unit tests are actually part of the problem, not of the solution, simply because they add to the code base. Writing elegant unit tests is as difficult as writing elegant code in general. Coders who only care about code coverage statistics (again, those formidable tools) are likely to miss some of the important test cases and to introduce subtle bugs into the unit tests. Test code can introduce technical debt, just as any other code.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 7:19 PM
Reply to this message Reply
Frank Sommers: "For instance, I worked years ago an a Web site/enterprise app using Perl. I was rather [in]experienced, and tended to repeat code all over the place. While I now frown upon that practice, I also recall that that code base actually worked really well, and was also easy to maintain: Since almost everything happening at a given place could be understood just by looking at a screenful of code, bugs were easy to fix and find."

And if the code that you repeated "all over the place" had bugs, you just corrected it "all over the place", right? If that is your idea of an "easy to maintain" code base, all the progress in software engineering during the last 50 or so years has been lost on you. Sadly, you are not alone. In the Java project I am working on, I am struggling every day with code written by coders who don't understand what's wrong with repeating the same code more than twice. They have been perfectly happy to type away the same boilerplate code hundreds and hundreds of times without ever thinking that there might be a better way. And no, it's nothing got to do with the "Java is so verbose" mantra. It is incompetence, and a lack of any aspiration for good design and elegance of expression. And heck, it works. Sort of. Sometimes. Everybody is doing it that way anyway, and don,t you forget, copy/paste is the most productive design paradigm that has ever been invented. And I daresay, the most widely practiced.

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 8:58 PM
Reply to this message Reply
> Peter Hickman: "Coding as guerrilla warfare is the only
> attitude that will get any results in the companies that I
> have worked for."

> Same experience. It simply doesn't help to point out, to
> suggest, to argue. No project manager will allow time for
> necessary code cleanup. What's in it for him? What can he
> bill the customer?
>
What's in it for the project manager is that he or she is doing a good job of management by balancing short and long term business goals. Although it may be true that in your experience you haven't encountered a manager who was able to do this, they do exist, and it is a notion I think there's a clear business case for.

Spending a bit of time doing entropy reduction after a release is good for the business. It gives the developers a time to work without stress while enjoying doing the fun job of improving the code, which makes the developers happy. And happy, refreshed developers are good for the business. And it has a long term debt-management payback of keeping the system able to gracefully accept changes, which is good for the business long term.

Now, it is up to the management to decide how to balance long and short term goals, and if they decide that short term is more important, I wouldn't second guess them. So long as they understand the tradeoffs of accumulating debt, they can make an informed decision.

> The only way I know of producing
> quality code is to simply do it, without asking. It can
> make you enemies, though.
>
I agree in general, but it is all about extent. To what extent should I produce the best code I possibly can? The best code I can generate is very good, but expensive because it takes me more time to produce. I think in general developers should try and create good code, but each developer is a mini-manager who has to make return on investment decisions. And it is possible that you can invest too much on quality, though admitedly the problem is usually the opposite.

> Vincent O'Sullivan: "There is one code quality tool
> whose use used to be widespread but which pretty died out
> (in my experience) about ten years ago. It requires no
> installation and provides an ideal mechanism for
> disseminating good practice across a team. It's the code
> walk-through."

>
> Again, I second. What I experience is a reluctance to
> engage in any discussion about code quality, about style,
> a reluctance to exchange and learn from each other.
>
You're doing it here at Artima right now. Perhaps you could try to start something like a monthly brown bag lunch where you work in which you get together with your collegues and discuss such issues.

> Instead, we now have sterile code convention documents,
> sometimes so silly as to prescribe in detail where a blank
> can be entered with impunity. I completely disagree with
> those who say that automated "code quality tools" can help
> ensure code quality.
>
I think the static analysis tools are like little nit-picky nannys that point out things you may have done wrong. They can help you find things that you didn't prevent in other ways, but they are not sufficient to achieve quality. I think there helpful mostly as a way to polish otherwise pretty clean code. If you use the regularly as you go along, I think they can help guide you in a quality direction.

> Sigh. Same for unit tests. Unit tests
> are actually part of the problem, not of the solution,
> simply because they add to the code base. Writing elegant
> unit tests is as difficult as writing elegant code in
> general. Coders who only care about code coverage
> statistics (again, those formidable tools) are likely to
> miss some of the important test cases and to introduce
> subtle bugs into the unit tests. Test code can introduce
> technical debt, just as any other code.
>
I think unit tests are just great to have, but I don't want to write them. They are expensive to write and maintain. They inflate the amount of code in your project around four-fold, and although they are really great at finding problems when you refactor and make changes, I've found they also tend to break a lot when refactoring in ways that don't help. In other words, when you refactor a test fails not because you broke the code in your refactoring, but because you broke the test. This is especially an issue when doing a major refactor. All the tests break, and it takes a long time to get them running again.

I do really like test-driven development, but I'd really like to minimize the amount of tests I actually write by hand. We have on the drawing board several ways we'd like to try generating unit tests from our DSLs. The code coverage tool isn't a substitute for thinking, but being able to visualize our test coverage is really nice I find. I'd like to get as much coverage as I can with writing as few tests by hand as possible. Right now our test coverage is rather poor, and it is definitely an area I'd like to improve on, because I think those tests really will help us move quickly.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 9:36 PM
Reply to this message Reply
> And if the code that you repeated "all over the place" had
> bugs, you just corrected it "all over the place", right?
> If that is your idea of an "easy to maintain" code base,
> all the progress in software engineering during the last
> 50 or so years has been lost on you.

Actually, it's a bit ironic about your "lost on you" comment. One hard-learned principle of structure programming that appears to be "lost" in the quick condemnation of repeated code is that shared code increases coupling between modules in much the same way global variables do.

So while it's true that duplicate code would require multiple corrections of discovered bugs, it also protects you against a bug introduced in one of the copies. This typically happens when different teams working on different projects share common code. One of the teams makes an appropriate change (for their project) in the common code which, unknown to them, creates a bug for the other team. Suddenly the other team has a bug with no clue how it came about.

Obviously, shared code should be managed carefully, but it can introduce problems that otherwise wouldn't occur.

The point is that there are always tradeoffs no matter what tthe politically correct answer of the day is.

Flat View: This topic has 97 replies on 7 pages [ « | 1  2  3  4  5  6  7 | » ]
Topic: Where Did All the Beautiful Code Go? Previous Topic   Next Topic Topic: Dynamic Function Overloading


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us