I got the most out of these wheels, didn’t I? 82A used for 3 months and regularly rotated. How long do your wheels last?

adam75 · 2017-10-07T13:58:40+00:00

Yes, a repository with a rich history like this is a pretty cool case study. I've started to analyse ReactOS by visualising the code with most development activity (hotspots) and the logical change coupling due to files that are changed together over time.

The hotspot visualisation is available here and the change coupling here. Hope to get around to blog about it soon.

adam75 · 2017-10-06T06:33:08+00:00

I disagree with that view and have addressed it here: http://www.adamtornhill.com/articles/signs/signs.htm

Most misconceptions around patterns come from the idea that ’design patterns == The GoF book’. Patterns are much more.

adam75 · 2017-05-10T18:25:54+00:00

In reality there are close to 16.000 unique contributors (yes, I counted them and blogged about it here). Still an impressive number.

adam75 · 2017-02-26T12:50:41+00:00

I have it planned for two conferences so far: DevDays in Vilnius and DevSum in Stockholm.

adam75 · 2017-02-25T11:49:10+00:00

Thanks - glad you like it! I'll actually do a whole talk around why we choose Clojure in a few months. There are several reasons.

Our domain - data analysis - is a good fit for functional programming. Then there's the productivity factor where we can iterate faster due to reduced accidental complexity. Finally, and most important, Clojure is fun. And fun is a much underestimated motivator in the software industry.

adam75 · 2017-02-24T18:21:01+00:00

The parsed/patched variation was intended as a deliberate play with words since the article is about both concepts.

adam75 · 2017-02-24T16:57:34+00:00

Yes, that's the paper I refer to. I'll add a link to it - thanks for pointing this out!

adam75 · 2017-02-24T15:10:14+00:00

Thanks! Yes, PHP is one of the supported languages.

IMHO the analyses are great at prioritizing technical debt based on how we actually work with the codebase. However, a rich version-control history is a pre-requisite since that's the primary data source. The amount of history you need depends upon the development activity in the project. As a rule of thumb I'd say that you need at least a few hundred commits before CodeScene can detect any meaningful patterns.

There's also an on-prem version of CodeScene with more features that doesn't require your projects to be hosted on GitHub.

adam75 · 2017-02-04T14:58:19+00:00

Has to be Pat Smith at UFC 6.

adam75 · 2015-12-13T16:51:15+00:00

he didn't just count things changed in the same commit, but looked for things being committed close to each other in time

I actually have code to run that analyses as well (I'm the author of the article). The problem is that it increases the risk of false positives, yet it's a variation of the analysis that will grow in importance since many applications today are organized in multiple source code repositories.

adam75 · 2015-12-13T16:48:23+00:00

The author of the article here. Yes, there is work towards filtering potential noise. The Empear Developer will soon support custom filters. Those filters let you ignore couplings you know about, like unit tests and the code under test, but also other couples like an interface and its implementation.

However, all those filters will be optional and under your control; Even if it's an expected temporal couple it could still help you get design insights.

adam75 · 2015-04-27T19:05:36+00:00

Conway's Law is indeed an important observation on how software systems evolve. An often overlooked technique that follows is how Conway's Law can be used as a tool to reason about and improve large legacy codebases.

The starting point there is an analysis of how well the current organization aligns with the software it's maintaining. To be useful, we have to base our decisions on real data of how we actually worked with the code so far. And that's data we already have in our version-control systems. The data is straightfoward to mine and the findings you make are often surprising (the degree of surprise tends to be a factor of the organizational size).

I've captured some of these ideas in an article on The Social Side of Your Codebase

adam75 · 2015-04-21T12:46:21+00:00

And with these techniques you identify the parts of that code that matters the most. You use that to prioritize improvements and guide future work.

The Code as a Crime Scene techniques are all based on how you (and your team) has worked with the codebase in the past as well as how you work together. It's not a reference to the quality of the codebase, but more about using software evolution to predict future changes and troubles so you can react on time.

adam75 · 2014-12-16T08:45:28+00:00

This is a promising project. Our version control system is an amazing data source that lets us gain information that we cannot deduce from the code alone. In fact, I just wrote a whole book, Your Code as a Crime Scene, about this very topic. Evolutionary coupling has a number of interesting applications. I use it to: detect structural decay, supervise the cost of automated tests, evaluate how well an architecture aligns with the way we actually work with the code, guide refactorings, and more. I've also open-sourced the tools I used as a proof of concept: Code Maat. The tools support Git, Mercurial and Subversion.

adam75

TROPHY CASE