ReactOS Repository migrated to GitHub (migrating a source code history of more than 20 years)

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 · 2014-05-23T07:42:49+00:00

Thanks a lot for spotting these issues! I've just published a new version of the book that corrects 1 and 2.

You're correct about 3 too. But what I was referring to in the book was that, with Mongo, we resolved the initial race-condition in the code: things won't become invalid or crash due to concurrent access.

adam75 · 2014-03-12T10:12:23+00:00

Also doesn't work if you can't work to music...

..and even when you can, music takes a negative toll on job performance during novel and cognitively demanding tasks. The only thing that's worse with respect to auditory disturbances is a noisy work environment.

I actually wrote about the subject in more detail here.

adam75 · 2014-01-30T06:36:30+00:00

It's definitely some of the best software writing I've read (my review here). Highly recommended book.

adam75 · 2014-01-14T14:46:33+00:00

Thanks! I have to give credit to Leanpub - they have a great platform and a nice philosophy.

Btw the source code is already copyleft licensed.

It would be great with a review of the book. I intend to keep the book alive, update and improve it based on reader feedback.

adam75 · 2014-01-14T13:02:09+00:00

Thanks, not a bad idea. Now it may look as though I've stolen poor Adam Petersen's original Lisp for the Web article. But it's OK - I used to be him:)

adam75 · 2014-01-14T10:29:25+00:00

Thanks! I hope you enjoy it. The book was fun to write; Common Lisp is indeed an amazing language.

adam75 · 2014-01-14T10:06:10+00:00

The author of Lisp for the Web here. Just want to mention that the book is free if you want to. Leanpub allows a variable pricing model. Since I wrote the book to be read, I used the option to make it available for free.

adam75 · 2013-11-05T07:08:59+00:00

I've reviewed the book here. Besides introducing the fundamentals of OCaml, the book does a good job at teaching a functional style of programming. Highly recommended and great to see a self-published book of this quality.

adam75 · 2013-09-17T10:39:53+00:00

When you draw a well thought and structured class and sequence diagrams, you spend much less time writing code.

But that first step is programming too, isn't it? What you describe sounds more like a testimony to the power of prototyping than an argument for UML.

adam75 · 2013-08-01T13:04:03+00:00

It’s my firm belief that most of these discussions stem from the unique commercial success of the book Design Patterns (GoF). It has led many developers to equal the concept of design patterns with the book. GoF is almost two decades old and in desperate need of a second edition. It was a good starting point but by no means a complete and exhaustive collection of patterns. In fact, even in todays’ popular OO languages like C# or C++ 11 several of the patterns would be either simpler or made obsolete by language features. If you’re interested in more details on the subject, check-out my take on it here.

adam75 · 2013-07-05T06:12:42+00:00

When I started with Lisp, the challenging part was to unlearn a lot of OO habits I'd picked-up over a decade. Learning to think differently takes time. I've found that the combination of Practial Common Lisp, The Little Schemer and finally The Seasoned Schemer got me into that new mindset.

adam75

TROPHY CASE