[LLVMdev] technical debt

Jan Sjodin jan_sjodin at yahoo.com
Thu Jun 7 08:12:48 PDT 2012


We already have a list of technical debt, just look at bugzilla (code-cleanup). There has been many refactoring efforts, e.g. one major was to MC by Evan Cheng last year. Before the refactoring was done, it was clearly a technical debt, because the refactoring only fixed violations of the design. Dan Gohman has been pointing out some design debt about the LLVM IR. In general, it is very easy to become used to bad living conditions because the are seen as "natural" and people generally try to be happy with what they have. Code tend to slowly get worse without anyone taking much notice, people are busy, and the code looks good enough. Lack of understanding of the design and not knowing the better way of doing something is often a cause of adding to the technical debt. I don't know if there is an easy way to lessen technical debt, other than to think more and type less, which might not be in a developers mind when a deadline is close. One thing that might
 help would be to write a couple more lines for code reviews, and explain why things are the way they are, and if they can't be easily explained something else should be done e.g. documentation or refactoring to make the code simpler (add to bugzilla if it can't be done at the time).


- Jan



>________________________________
> From: Daniel Berlin <dberlin at dberlin.org>
>To: reed kotler <rkotler at mips.com> 
>Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> 
>Sent: Monday, June 4, 2012 8:17 PM
>Subject: Re: [LLVMdev] technical debt
> 
>Can we get back to the substantive discussion about your ideas for
>lessening the technical debt?
>
>On Mon, Jun 4, 2012 at 8:05 PM, reed kotler <rkotler at mips.com> wrote:
>> Well, differences of opinion is what makes horse races.
>>
>> Reed
>>
>>
>> On 06/04/2012 04:57 PM, Daniel Berlin wrote:
>>>
>>> On Mon, Jun 4, 2012 at 7:53 PM, reed kotler<rkotler at mips.com>  wrote:
>>>>
>>>> On 06/04/2012 03:25 PM, Daniel Berlin wrote:
>>>>>
>>>>> I'm pretty sure neither llvm nor clang have any technical debt at all.
>>>>>
>>>>> On Mon, Jun 4, 2012 at 5:18 PM, reed kotler<rkotler at mips.com>    wrote:
>>>>>>
>>>>>> something to think about as llvm and clang grows.
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Technical_debt
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>> I hope you are joking.
>>>>
>>> Why would I be joking?
>>>
>>>> It's not meant as a criticism of llvm or clang but there is already an
>>>> enormous amount
>>>> of technical debt.
>>>
>>> I don't see that.
>>>
>>>> It's something to try and get a handle on before it gets out of hand.
>>>
>>> The consequences will never be the same
>>>>
>>>> Documentation is one area where it is accumulating fast but there are
>>>> others.
>>>
>>> I think LLVM is incredibly well documented
>>>>
>>>> Testing is another area.
>>>
>>> It also has at least 10-15 tests.
>>>>
>>>> Tablegen alone has huge technical debt.
>>>
>>> I'm sorry you feel that way.
>>>>
>>>> To me, there should be a cap placed on the number of lines of code in
>>>> llvm.
>>>
>>> Will there be a credit offset system?
>>>>
>>>> Like a budget. We should try and rewrite and refactor to keep the number
>>>> of
>>>> lines from growing
>>>> without bound.
>>>>
>>>> At this point lots of patterns should be developing where other tools
>>>> (like
>>>> tablegen) could be
>>>> written to reduce the amount of code and make things more understandable.
>>>
>>> I agree. We should macroize most of the passes so they aren't so wordy.
>>>
>>>> Reed
>>>>
>>
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu        http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/e64cbcfd/attachment.html>


More information about the llvm-dev mailing list