Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Software Design X-Rays: Project Team Size

 
Ranch Hand
Posts: 282
Eclipse IDE PHP Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adam,

I maintain a handful of open source projects in my spare time.  I am the sole developer on these projects (I very rarely get pull requests or patches).  How well do the principles in your book apply to projects that only have a single person working on them?  Are the principles in your book more centered around large teams?  Thank you!

Michael Angstadt
 
Author
Posts: 21
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Michael Angstadt wrote:I maintain a handful of open source projects in my spare time.  I am the sole developer on these projects (I very rarely get pull requests or patches).  How well do the principles in your book apply to projects that only have a single person working on them?  Are the principles in your book more centered around large teams?
Michael Angstadt


The principles in the book become more important with larger teams and systems. Somewhere around just 5-7 developers, social and organizational factors tend to become just as important as technical aspects. This is clearly not the case in your situation. For example, you're likely to have a high system mastery as you've written all code by yourself, and you don't need to consider aspects like coordination or loss of knowledge due to former contributors.

That said, I do use these techniques on my own side projects too. The value isn't as big as on larger projects, but the analysis techniques might still provide some insights that I use to guide refactorings:

* I use hotspots to get a visual overview of my codebase. This helps by giving me a different perspective as I get to view the code from an evolutionary perspective. It's quite easy to spot modules that start to grow out of control so that we can act on it.
* I'm also interested in long-term complexity trends. If I find a significant hotspot, is it code that continues to accumulate complexity and is likely to become worse in the future? A complexity trend answers that question.
* Finally, and perhaps most important, I look at the temporal dimension to identify change coupling in my code. That is, are there certain components/files/functions that I regularly have to modify together? If yes, did I expect the coupling or is it a surprising finding?

We developers seem to lack an intuition for change coupling and, hence, such an analysis will often provide insights about implicit dependencies that we cannot see in the code itself. I use the technique all the time to identify units to combine, split, or even re-design.
 
You're not going crazy. You're going sane in a crazy word. Find comfort in this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!