Code Simplicity

Clues to Complexity

Here are some clues that tell you that your code may be too complex:

  • You have to add “hacks” to make things keep working.
  • Other developers keep asking you how some part of the code works.
  • Other developers keep mis-using your code, and causing bugs.
  • Reading a line of code takes longer than an instant for an experienced developer.
  • You feel scared to modify this part of the code.
  • Management seriously considers hiring more than one developer to work on a single class or file.
  • It’s hard to figure out how to add a feature.
  • Developers often argue about how things should be implemented in this part of the code.
  • People make utterly nonsensical changes to this part of the code very often, which you catch only during code review, or only after the change has been checked in.

That’s what I can come up with off the top of my head. What are some others?

-Max

14 Responses to Clues to Complexity

  1. • The code doesn’t play well with other code (weak or no API).
    • Each function seems to require a custom input type.
    • Compilation or interpretation is slow.
    • The project requires several programming languages.
    • It would be really hard to decouple the project with its dependencies or switch to alternative libraries.
    • Developers talk about rewriting the whole thing from scratch.

    • Max Kanat-Alexander says:

      Yeah, those are good! :-) Although I wouldn’t say that slow interpretation/compilation or the need for several languages are necessarily indicators of complexity. Some languages just have slow compilers, some projects are just large, and sometimes you have to use multiple tools to get the job done.

      -Max

  2. John says:

    How about “Management seriously considers hiring more than one manager to manage the developer working on a single class or file” :)

  3. Jerome says:

    A few other ones:

    - Your methods parameter lists grows out of control over time.

    - You feel the need to comment your control block endings (I call it ‘if’ inflation)

    - Writing a good coverage test would require more code than the method you want to test.

    • Max Kanat-Alexander says:

      Yeah! Those are pretty good! :-)

      Although, as far as test-writing goes, I’ve actually found it pretty common that tests can be larger than code. I think that’s probably more an issue of the complexity of the requirements as opposed to the complexity of the code.

      -Max

  4. Raghu says:

    After reading Simon’s comment above, I went to the site and found this.

    http://thedailywtf.com/Articles/Serious-String-Validation.aspx

    ~raghu

  5. Palo says:

    Hi Max, I really like your blog posts. Last year I was working on a batch system for computing statistics from large datasets. I order to add a new bussiness rule I had to check and/or modify several non-related places including spring beans, property files and other stuff, all of these were trivial, but it was easy to make a mistake (for example there was a DB2/Oracle decimal/integer issue which no-one got right at the first time). So I think that a system is complex when it’s very easy to make a mistake (the consequence is “You feel scared to modify this part of the code”)

    • Max Kanat-Alexander says:

      Hey Palo! Thanks for your kind words! :-)

      Yeah, I agree, “it’s too easy to make a mistake” is a very good one. :-)

      -Max

  6. Srihari S says:

    If your code has smells, it is complex. Refer WIKI:Code Smells.

  7. Steve Bush says:

    I read Code Simplicity cover to cover yesterday! (Do ebooks have “covers”?). And enjoyed it! I’d say about 50% I agree with and the remaining 50% I strongly agree with! I guess I could nit-pick a couple of points, (and look forward to doing so at some future date!), but on the whole, I agree mostly with your initial statement that, whatever else it may be, it’s a start! And a very *workable* start!

    I wouldn’t mind seeing a blog/class/lunch series, with one rule or law per class period (or blog entry) put up for discussion! That would be an interesting conversation!

    I have two irrelevant-to-the-point-of-coding comments to add:

    One totally new thing I got from the book was the physical organization. Each Law, Rule, Fact, Definition, is identified as it occurs and then when I got to the end, I was treated to an Appendix listing every one of them! That created a fantastic review of the whole book! I liked that a lot, it was like scanning over, almost mentally re-reading, the entire book in the last 5 minutes! Awesome!

    Another irrelevant but maybe interesting point was the WAY I read it: via iPad iBooks app. I read an AWFUL lot, but almost always via a web browser. I notice I pretty constantly scroll as I read; on the iPad my thumb keeps the text rising like an auto-prompter so that my eyes always stay at about the same height; and on the Mac, I read with two fingers resting on the trackpad doing the same thing. But iBooks keeps the text stationary and my eyes went from top to bottom. I can’t say whether that was superior or not, I just struck me as different, and a reminder that we’ve come a long way since, what are they called, those paper things, oh yea, BOOKS!

    One humorous stupidity: I went to the iBook table of contents once and it only goes to Chapter 2 on the screen. I spend a good five minutes trying to get the remaining chapters to display. The page wouldn’t turn! I almost gave up and decided it was a bug, when I realized, the toc SCROLLS!!!!!! :-)

    Anyway, you have done a very nice job, thank you very much! I enjoyed it, and I’m sure my programming will gain from it in the future!

    Steve

    ————-
    “We are having fun now!”

  8. Vidhyut says:

    Complex software mostly have large dependency. So if you can not reuse a class from one project to another, It’s a signal that, you have tightly coupled and complex system.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>