The Artima Developer Community
Sponsored Link

Weblogs Forum
Where Did All the Beautiful Code Go?

97 replies on 7 pages. Most recent reply: Apr 14, 2006 9:55 PM 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 | » ]
Steve Holden

Posts: 42
Nickname: holdenweb
Registered: Apr, 2003

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 9:01 PM
Reply to this message Reply
Advertisement
Bruce places his finger on a very important pulse in suggesting that it's important to understand what we mean by "cheaper". As in so many other cases, software development is a lot like life ["Life? Don't talk to me about life. I've got this pain in all the diodes down my left side". But I digress].

There's optimisation and there's suboptimisation. The problem is that you can only truly optimise when you take all requirements into account, including future ones. At the moment the humna race is busy committing suicide in the name of "efficiency" and "profit". Unfortunately, optimising "profit" for a few people in South America means deforestation in the Amazon, which is suboptimal for the survival of the race as a whole. Politicians everywhere unfortunately gain power by appealing to the vested interests of the majority (in a democracy) or the minority (in a power-based oligarchy). Ultimately the golas that are served are those of the wealthy.

Longer-term thinking has gone out of fashion in software development (as it appears also to have done in government) as agile techniques have forced the focus on "delivering business value", and forethought has become tainted with the stigma of "big up-front design". But in fact certain projects (usually big ones) will benefit from up-front design, because an experienced software architect will be able to perceive value in the development of components whose design would be hounded out of the typical agile project with cries of "YAGNI".

Dammit, the customer is entitled to tell me what's important to her in terms of delivering value to the business. But if I see her problem definitions proceeding along the same well-worn tramlines that fifteen other clients have sent me down before then I reserve the right to say "You may think you won't need this, but trust me, you will".

I realise this is unfashionable in a world where disorganisation is the new planning, but I no longer care. If you enjoy the parable of the cathedral and the bazaar I would offer the following observation: cathedrals are beautiful, typically take decades to build, are inspired by a vision of beauty, and bring us closer to God; bazaars are usually ugly, grow by accretion as needed, are inspired by a vision of personal profit, and get in the way of spiritual development.

There's no such thing as a short-term vision. If Alan Kay had been concerned by YAGNI he would never have conceived of the Dynabook, which is with us today largely because people like him see past the limitations of current technologies and push the future towards visions that are presently unrealisable.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 29, 2006 11:37 PM
Reply to this message Reply
> I see a lot of agreement in the software community poor
> quality code slows you down. Where I see disagreement is
> on how to manage technical debt. What is your approach?
> When do you take on technical debt? When do you invest
> time to pay it off?

In a sense I'm not sure I even understand the question. Some people do a lot effort on coding and achieve very poor code quality and others write quick solutions and a few unit-tests that nail down the things just right. So it has nothing to do with "quick and dirty". I also don't think that the question is strongly related to deadlines or do you think open source software is cleaner and better structured? In my experience programmers that are not busy because they have to wait for some other peoples work or decisions to be made are not refactoring their old code but surfing in internet or doing private corresponcence.

Systems evolution is still for real as well as an improved understanding of the techniques in use and the application domain. So we observe code becomes a historical relict all the time while others of the same age "lasts forever". It is indeed hard to manage this because it moves beyond micro-optimisations described by refactoring patterns. As projects grow they need another level of control that is driven by the system itself, a kind of "internal coding standard" and a set of "internal design pattern". Those pattern do not need to leave the boundary of the individual system so they are not by any means universal but deeply situated. They might even be a poor solution in another context but they create a shape of the particular system ( isn't this the way experience architects think about context and situated solutions that are not transferable while mediocres built the same buildings everywhere? ) That's similar to programming language idioms and it takes time to grasp them and find out what they are. But I'm not sure what can be said about this? Who to be creative and precise as a programmer?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 1:31 AM
Reply to this message Reply
> 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.

MS is writing spaghetti code, I can confirm that. I have seen Win32 source code from the leaked sources two-three years ago. I hunted for those sources not to get inside knowledge of Win32, but to see how MS code is, qualitywise.

One particular example of spaghetti code is Win32 widgets. If you could take a look at the standard list box widget code, you would see a mess of macros, temporary variables, lots of if-then-else, lots of bitwise arithmetic and casts, spread over 11,000 lines of code. I tried to decipher how the whole thing works, but I just gave up.

I have tremendous respect for Microsoft because they make the whole think work, even if it works 99% of the time. But their code is spaghetti, and there is no doubt about that. The reluctance to release the code to the general public, even for a primitive Windows version, confirms that in my eyes.

Beautiful code is a myth; beautiful code exists only in offices of academia. The rest of the world has to fight over code on a day-by-day basis. Who is to blame for that? the IT industry, because it has a mentality of "doing what works" instead of "doing it right". Billion of dollars is spent in downtime and maintenance, security and safety violations, because of that.

Dag Blakstad

Posts: 7
Nickname: dag
Registered: Aug, 2003

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 3:19 AM
Reply to this message Reply
There are many facets to what beautiful code is, and not least what ugly code looks like. To make it even more complicated this not necessarliy the same as code that is easy to maintain, or that is effective and scales well runtime.

The title Where Did All the Beatiful Code Go? makes a good job attracting readers, but does not hit the nail on the head. What I mean by that is there certanly something missing in software community. There should be something like pre-accepted solutions to common problems (design patterns and components), enforced code & architecture reviews by 3rd party in projects larger than 6 man-months and the universities teaching programming could certainly do a better job teaching how to solve real problems. I think books like The Pragmatic Programmer: From Journeyman to Master should be required to read and understand before anyone is allowed to do professional software development.

I think that online communities like Artima and DeveloperDotStar and http://www.booch.com/architecture/blog.jsp is on the right path by sharing information, but they are not used much by the developers that need it most. How can this knowledge be made that common, so that no develepers is inventing bad solutions to problems solved excellently by others?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 6:20 AM
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.

I'm sorry. I'm looking a that post and I don't see where I list a set of issues. I stated that there are common issues between large projects and small projects. What those are depends on which projects you are referring to. What you are sayng here doesn't make any sense. I'm not sure if you are being purposely obtuse or are just not familiar with logical propositions.

> > > 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.)

Bill Smith says you are wrong. Bill Smith is an expert in fallacies. You shouldn't disagree with Bill Smith because Bill Smith knows better than you.

I would say I agreee with this assesment:

http://en.wikipedia.org/wiki/Appeal_to_authority

But in any event you haven't truly appealed to authority because you haven't given an example of where Capers said that large projects don't make good examples for technical debt discussions. You took statement that says something else entirely and then drew your own conclusion and then attempted to attribute it to Capers Jones.

> -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.

No it's not. If we are going to discuss things you need to make your points and address my points. I'm not in a discussion with Capers Jones. I'm in a discussion with you. You haven't shown why being different makes big projects invald examples. You've asserted it but not demonstrated it in an logical or rational way.

At this point I don't feel I have anything to gain from discussing thie with you anymore. You seem to have nothing to contribute beyond mentioning "Capers Jones".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 7:43 AM
Reply to this message Reply
> > 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.

I think maybe I see where you are getting confused.

Consider these sets:

A: (123456)
B: (0123)
C: (4567)

Set A has common elements with B: (123). Set A also has common elements with C: (456). However, B and C don't have common elements with each other. In addition, B has elements that are not in A or C: (0) and C has elements that are not in A or B: (7).

You seem to think that because I have asserted that (some) large projects have common issues with (some) small projects, that the set of issues for a small project is either a single set for every project (clearly absurd) or a subset of the issue for large projects. This is clearly not implied by my statement as demonstrated above. Small projects have issues that large projects do not. For example, if a team member is lost on a small project, it's a serious issue if there were only 3 members to start with. If the project has thouands of developers, the loss of one team member generally has minimal impact on the overall effort.

I would also say that the smaller the project the less technical debt matters. On very small a.k.a trivial projects, technical debt may not matter at all. So for smaller projects technical debt is often not even an dominant issue. It's not until the project grows in size that the technical debt becomes a problem. My experience is that the cost of technical debt grows exponentially as the project grows. From these assertions, I claim that saying large projects aren't good examples for technical debt discussion is nonsensical, at least from the evidence that has been presented in this thread.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 8:25 AM
Reply to this message Reply
> 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.

Writing and maintaining tests are expensive, but how else are you going to consistently verify that your code is working correctly? I would argue that the most serious technical debt you can have is the lack of tests, and that the correct place to put a significant portion of your resources is into testing. Otherwise, how are you ensuring that your system is working correctly? Are you just saying "I tried it, and it worked for me, so you should trust me that it's working correctly"?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 8:51 AM
Reply to this message Reply
> Writing and maintaining tests are expensive, but how else
> are you going to consistently verify that your code is
> working correctly? I would argue that the most serious
> technical debt you can have is the lack of tests, and that
> the correct place to put a significant portion of your
> resources is into testing. Otherwise, how are you ensuring
> that your system is working correctly? Are you just saying
> "I tried it, and it worked for me, so you should trust me
> that it's working correctly"?

Based on some of the things you've written here lately, I decided to take a crack at Python (in the form of Jython) at work. I started using it as an ad hoc testing tool for my code during development but now I am looking at it as a tool for writing unit tests. There are definitely some pitfalls that I have found but because the Python scripts can be written so quickly it seems like there maybe something to this.

I would be interested in any experience you have with this or any comments on it.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 10:52 AM
Reply to this message Reply
My point was that there were not many bugs in that code, and it was a very successful project, but it was not beautiful code. It was ugly code that worked, was easy to maintain and develop, and did the job.

By contrast, I was later involved in projects that did aim at beautiful code, but failed because that code took too much effort to create and thus did not fit its purpose in a business environment.

The trick is to create beautiful code fast. Kind of like Mozart wrote music.

That works sometimes, but often it does not. In a business, there can't just be 2-3 developers, if you want grow that business. And when you have more developers, then it's like a city where you have Botticelli pieces sharing a street with graffiti. Yet, such cities do actually work. And some find beauty in graffiti, just as some find beauty in mind-blowing complexity.

Someone posted here earlier about MS widgets being spaghetti code. That reminds me of an article on Joel on Software on why one should not re-write one's software in a business environment. Old (and often ugly) code that's been around in production works, and has numerous bug-fixes, making it even uglier, but making it work possibly even better. What would be the business case for re-writing that code, if the code works 99% of the time, which is acceptable in the context of the user base? (And even a beautiful re-write might not result in significantly more reliable code.)

The business case would be to make developers happier, but that's not always a valid business case for shareholders. (And many developers, in a different context, happen to be shareholders, too, I suppose.) I have seen anecdotes about beautiful code resulting in increased shareholder value, but the evidence is so sketchy that I just don't see a causal relationship. I do see a relationship between code that works well and a business benefit (you can't really sell a product or service that does not work most of the time). But, as my earlier point was, "ugly" and patched code can work very well over time, much as ugly and patched city streets are capable of carrying traffic for centuries on. And maybe there is some beauty in <em>that</em>.

Yet, we need to remember that not all software is written in a business environment: there are academic environments, scientific environments, hobbyist environments, open-source environments, etc. It might be very appropriate in such environments to aim at beautiful code rather than "time-to-market," since the latter is not a concept.

And it is possible to create, say, an academic environment even inside a company, as many R&D departments have done. But then the purpose clearly must be kept in mind. For instance, if your research project becomes the basis of a product, and you move from the academic to the research environment, then the relationship to beautiful code must also change. We have to learn to freely move between these environments, just as a great musician can employ freedom and improvisation when playing jazz while adhering to exactitude in Beethoven.



> 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.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 11:12 AM
Reply to this message Reply
I find Frank Sommer's remarks simply ignorant. Please, this is not about writing code as Mozart wrote symphonies and Shakespeare wrote dramas. It is about sound craftsmanship. And yes, a well-crafted piece of work makes the maker happy, but it also makes the customer happy. The shareholder, it is true, doesn't care but this shouldn't prevent us, as professional software makers, to strive for quality in our work.

"But, as my earlier point was, "ugly" and patched code can work very well over time, much as ugly and patched city streets are capable of carrying traffic for centuries on."
I live in a city where each spring, the streets have so many holes it look as if they haven't been mended for decades. Yet, they have been mended just the previous year, every one of them. Those streets are capable of carrying traffic only because they are patched every year at great expense. Does it work? Sort of. Is it expensive? Yes. Is it good quality? No. Are the people happy? No, but they are used to it. It's just how it is.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 11:13 AM
Reply to this message Reply
> Someone posted here earlier about MS widgets being
> spaghetti code.

I think you mean me. I'll just say that I am not making any hard assertions on this just an educated guess.

> That reminds me of an article on Joel on
> Software on why one should not re-write one's software in
> a business environment. Old (and often ugly) code that's
> been around in production works, and has numerous
> bug-fixes, making it even uglier, but making it work
> possibly even better. What would be the business case for
> re-writing that code, if the code works 99% of the time,
> which is acceptable in the context of the user base? (And
> even a beautiful re-write might not result in
> significantly more reliable code.)

I have to agree completely if the code works and works very well. But what I see is often not that clear cut. We have code that works well, sort of. It works fine except those somewhat infrequent times that it doesn't but we can't figure out why because the code is overly-complex and overly long for what it's doing. There is almost no documentation and there is never time for someone to go on a spelunking expedition an figure out how it all works does and what parts don't really do anything.

That's not even the real problem. It's when we need to add new functionality that things get really ugly. Because each function of the system is basically monolithic, there's no way to quarantine the ugly parts. We have to get knee-deep into it start banging on it's fragile components. For example, adding a new field to the output requires dozens of code changes and many are non-trivial and could easily throw the code out-of-whack (for example: one process passes data in two arrays though half-a-dozen Objects and classes and there are dozens of dependencies against them. Modifying the order of one array with out modifying the other could cause massively incorrect output that might only be sporadic.

The point is that the cost of maintaining this code is very high and it's reliablity is low. When do you cut your losses and do something about it? It's a tough question, I think.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Unit tests Posted: Mar 30, 2006 11:34 AM
Reply to this message Reply
Bruce Eckel: "Writing and maintaining tests are expensive, but how else are you going to consistently verify that your code is working correctly? I would argue that the most serious technical debt you can have is the lack of tests, and that the correct place to put a significant portion of your resources is into testing. Otherwise, how are you ensuring that your system is working correctly?"

This would all be very convincing if unit tests would actually "consistently verify", "ensure that the system is working correctly". But they don't. They only ensure correctness for a very limited set of test cases. You can't expect test code to be of better quality than the code it is supposed to test. If a developer has missed something important when writing functional code, he or she will miss it again when writing the test code. Bill Venner's argument, with which I agree, pretty much deflates the hyperbole around unit tests and how they solve all software engineering problems. They are useful but not to be exaggerated. There is much more to testing than just unit tests. I don't even consider unit testing a part of actual QA, which should be rigorous and independent of development. Unit tests are a tool for development, they don't guarantee anything and they can become a burden, as Bill points out correctly, especially if the hype gets the upper hand and quality is misguidedly equated to unit test coverage.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 1:56 PM
Reply to this message Reply
> Writing and maintaining tests are expensive, but how else
> are you going to consistently verify that your code is
> working correctly?
>
By testing it. Unit testing is not the only kind of testing. I agree that if I had 100% unit test coverage, as Uncle Bob suggests we strive for, that I would have fewer problems. But we don't have that many problems in practice, and almost never very serious ones, because we test by hand as well as run unit tests. Among the problems we have had, most have had to do with misconfiguration on deployment, something that wouldn't have been caught with unit tests that ran just fine with proper configuration.

So it is a question of cost. I could write unit tests that checks each possible web page with a string of what's expected, for example, but as soon as I make one global change to the website, I'd break all those tests and have to go back and fix them, even though the site was actually fine. The tests would have broken, not the application. For look and feel stuff, I have deemed it more economical to just not create automated tests for that. Instead, we just test the software by hand before deploying.

> I would argue that the most serious
> technical debt you can have is the lack of tests, and that
> the correct place to put a significant portion of your
> resources is into testing. Otherwise, how are you ensuring
> that your system is working correctly? Are you just saying
> "I tried it, and it worked for me, so you should trust me
> that it's working correctly"?

I think that's too broad a statement. Whether and when you should write tests depends on the situation. What is it that you're considering writing automated tests for? Yes, if I spend money to write more tests, I can eliminate technical debt along the way, but at what cost? If I have to spend $10,000 to pay off a $1000 debt, it isn't worth it. Eventually you hit the point of diminishing returns, and there's where I think you should stop.

To me the interesting question is how do we know when we've hit that point. I definitely haven't at Artima. We had decent test coverage of Frank's first implementation of the account use case, for example, but as we started a major refactor that included creating our DSLs, those tests broke in a big way. We just shut them off, because what we'd like to do is explore automatically test much of the generated code. But at this point we have a test plan, about 23 steps we go through (all the use cases) that we test by hand before we deploy. It works. Yes, I have to spend time doing those hand tests each time, but I'd have to spend time writing unit tests too.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Unit tests Posted: Mar 30, 2006 2:04 PM
Reply to this message Reply
> This would all be very convincing if unit tests would
> actually "consistently verify", "ensure that the system is
> working correctly". But they don't. They only ensure
> correctness for a very limited set of test cases. You
> can't expect test code to be of better quality than the
> code it is supposed to test. If a developer has missed
> something important when writing functional code, he or
> she will miss it again when writing the test code.

I would claim that writing a unit test does actually help you find mistakes, because you often don't make the same mistake twice. I've heard XP people compare unit testing with double entry bookkeeping, which helped accountants prevent errors back before there were computers to check their work.

What I have found, however, is that we can't think of everything to test. So even if we have written every test we can think of, that doesn't mean there are no bugs lurking, because we may not have thought of something. I can give specific examples of where that's happened to me in the past. But just because we can't think of everything doesn't mean unit tests aren't valuable. I think they are extremely valuable, and although I take a less idealistic view than Uncle Bob, I still would like to have as much automated testing as I can afford for programs that I plan to build out to any decent size. I just want to avoid writing them by hand if possible, so I've got a few things on the drawing board for automating the writing of our automated tests.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 2:25 PM
Reply to this message Reply
> I find Frank Sommer's remarks simply ignorant. Please,
> this is not about writing code as Mozart wrote symphonies
> and Shakespeare wrote dramas. It is about sound
> craftsmanship. And yes, a well-crafted piece of work makes
> the maker happy, but it also makes the customer happy. The
> shareholder, it is true, doesn't care but this shouldn't
> prevent us, as professional software makers, to strive for
> quality in our work.
>
Hey, no ad hominems. Please attack the ideas, not the people. I'd really like Artima to stay a place people can have lively, but respectful, discussion.

I think the craftsmanship argument is important, but I think the most compelling argument for code quality is the business case of long-term maintenance. That's I think the best way to justify to upper management that you're putting a week of post-release entropy reduction on the schedule.

> "But, as my earlier point was, "ugly" and patched code can
> work very well over time, much as ugly and patched city
> streets are capable of carrying traffic for centuries
> on."
> I live in a city where each spring, the streets have so
> many holes it look as if they haven't been mended for
> decades. Yet, they have been mended just the previous
> year, every one of them. Those streets are capable of
> carrying traffic only because they are patched every year
> at great expense. Does it work? Sort of. Is it expensive?
> Yes. Is it good quality? No. Are the people happy? No, but
> they are used to it. It's just how it is.

Well, the fact is that you haven't moved, and you probably pay taxes. So the roads are good enough to get you to pay for them.

Users put up with a lot of pain if they are getting what they want from the software. Getting a quick but mediocre product to market first is an economic niche, and I suspect it always will be. Back in 1996, I bought Java in 21 Days to learn Java, because it was the only Java book on the market at that time. It was full of errors, and nowadays I would never buy it because I think there are far better introductory Java books, but at the time it was all that was available. I put up with the errors, because the book served my need of helping me learn Java. I suspect it made a lot of money.

Flat View: This topic has 97 replies on 7 pages [ « | 1  2  3  4  5  6  7 | » ]
Topic: Shuttleworth Foundation Workshop on Analytical Skills Development Previous Topic   Next Topic Topic: Software Architecture is Leadership

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use