Tracking Technical Debt with TechDebtAttributes

Technical debt can build up over time, slows down development speed, and could increase the risk of defects.

If you work in situation where it’s not always possible to create clean code or you’ve inherited a legacy application you may wish to start cataloguing where and how painful tech debt is.

Introducing TechDebtAttributes

image

I just released an initial NuGet version of an open source project called TechDebtAttributes.

It allows attributes to be used to mark classes, methods, etc as containing technical debt.

When the [TechDebt] attribute is applied you need to specify 2 mandatory values: pain and effort to fix.

Pain is a relative measure of how painful the tech debt is; for example how much it slows you down when changing code, how unhappy you are with it, how many defects are caused by it, etc.

Effort to fix is also a relative measure of the ease, amount of effort/time it will take to fix and remove the debt.

Optionally a description of the debt can also be specified.

Once attributes have been applied, a (string) report can be generated:

***Start of Tech Debt Report - finding all [TechDebt] attribute usages

Benefit to fix: 4999.5  AnotherExampleUsageAssembly.Mango Pain:9999 Effort to fix:2
Benefit to fix: 1666.7  Void .ctor() Pain:5000 Effort to fix:3
Benefit to fix: 5 Quick fix to stop stupid stuff happening sometimes Void SomeMethod() Pain:5 Effort to fix:1
Benefit to fix: 2  ExampleUsage.SillyEnum Tomato Pain:47 Effort to fix:23
Benefit to fix: 0.5 What kind of cheese is this? ExampleUsage.Cheese Pain:3 Effort to fix:6
Benefit to fix: 0.4 What exactly is inner cheese ExampleUsage.Cheese+InnerCheese Pain:3 Effort to fix:8
Benefit to fix: 0.3 This really is silly ExampleUsage.SillyEnum Pain:2 Effort to fix:6
Benefit to fix: 0.2 This is dumb, we should remove it ExampleUsage.ISomeDumbInterface Pain:10 Effort to fix:44
Benefit to fix: 0.1 This should be moved to it's own interface Void Y() Pain:10 Effort to fix:100
Benefit to fix: 0 There's a lot of work to fix this whole class for not much gain ExampleUsage.SomeThing Pain:1 Effort to fix:200

***End of Tech Debt Report.

You can also use a method to specify the maximum total pain you’re willing to accept, if the total pain from all [TechDebt] attributes exceeds this an exception will be thrown and your test will fail.

See the Readme on GitHub for more info.

If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.

SHARE:

New Open Source Project–Named Colors

I’ve been tinkering with an idea for a new open source project called NamedColors.

As its name suggests, it’s a list of color values (hex RGB) with associated names. In addition, a number of related “emotions” can be associated with each color.

A Named Color is defined as:

<NamedColor>
    <Name>MetroUITeal</Name>
    <RGB>00aba9</RGB>
    <Emotions>
    </Emotions>
</NamedColor>

You can see the current (short) list on GitHub.

The idea is to create a number of projections for use in different programming languages / platforms. For example CSS, Sass, and .NET PCL.

The project is in its early stages at the moment, and I’m not sure what applications people will find for it – it will be interesting to see what happens.

Projections are created using T4 templates.

There are other projections planned, such as a XAML dictionary of colors and brushes.

If anyone has any other ideas for projections feel free to add an issue or send me a pull request – also for adding other named colors.

Eventually for .NET there will be a NuGet PCL available containing all the named colors and way to say “give me a sad color”, etc.

SHARE:

FeatureToggle 2.2Released

Release 2.2 of FeatureToggle is now available via NuGet.

This release adds a single new toggle: HttpJsonFeatureToggle.

This toggle gets it's enabled state from a JSON HTTP endpoint.

Configuration should be the url where the JSON configuration lives, e.g:

<add key="FeatureToggle.HttpJsonTrueToggle" value="http://localhost:8084/api/test/getenabled" />

As with all the toggles, if url is not available then an exception will be raised, rather than assuming either enabled or disabled.

The expected JSON that should be returned is in the form:  {"enabled": true} or  {"enabled": false}

Documentation here.

I’m thinking the next major release will be Version 3, planned changes here.

SHARE:

FeatureToggle 2.1 Released

Version 2.1 of my open source feature toggling library has just been released.

This new version contains two new toggles.

The RandomFeatureToggle as its name suggests will randomly enable/disable a feature.

The EnabledOnDaysOfWeekFeatureToggle allows configuration of a toggle to become enabled on specific weekdays.

 

Check out the documentation and release notes for more info.

SHARE:

New RavenDB FeatureToggle

I just published new NuGet package for my open source .NET feature toggling library.

This package allows you to turn features on/off depending on what’s configured in a RavenDB database.

PM> Install-Package FeatureToggle.RavenDB

Extract from documentation:

BooleanRavenDBFeatureToggle

This toggle is not available on Windows Phone or Windows Store apps.

This toggle get it’s value from a RavenDB database.

Create a Toggle for the feature you want to control by inheriting from BooleanRavenDBFeatureToggle:

private class SaveToPdfFeatureToggle : BooleanRavenDBFeatureToggle{ }

Add RavenDB connection string to app/web config:

<connectionStrings>
    <add name="FeatureToggle.SaveToPdfFeatureToggle" connectionString="Url = http://localhost:8080;database=FeatureToggleInterationTests"/>    
</connectionStrings>

The database should contain a collection called “BooleanToggleSettings” with a document for every toggle that contains a property “Enabled”:

{
  "Enabled": true
}

Check out the test setup to see an example of writing some toggle config entries.

SHARE:

FeatureToggle Version 2 Released

FeatureToggle logo

Version 2 of my open source feature toggling .Net library has just been released to NuGet.

V2 introduces a number of breaking changes – see release notes. It also include binary Windows Store DLLs as opposed to code-only.

Version 2 will form the base for new feature in the future.

FeatureToggle.Core has been introduced as a portable class library.

For more details see the documentation, or the examples.

SHARE:

Find a Designer for your Open Source Project

Are you running an open source project? Need some help with your project CSS, perhaps a NuGet logo, or help with your GUI?

It’s hard to find designers, so I made OS Designer Finder.

OS Designer Finder screenshot

If your open source project needs some design help, simply create a GitHub issue (CodePlex support coming soon).

You just need to entitle your issue “designer wanted” followed by the type of work, so for a logo you’d use a title of “designer wanted logo”. For CSS help: “designer wanted css”.

To see how to structure an issue, see this example issue.

It’s currently in a working beta. Please help spread the word to both open source developers and also any designers you know.

SHARE:

5 Ways to Contribute to Open Source - It’s Not All Code

Open source is cool. Most of us use at least one open source project in our daily work. Even if we don’t, the websites we visit probably do.

It’s easy to contribute to an open source project, even if you don’t write code.

Contributing To Open Source pyramid diagram

This diagram shows some of the different ways to contribute.

Tweet About the Project

The easiest way to contribute to a project is to either Tweet about it to tell people that it exists, or send a Tweet to the contributors / creators. Most open source authors don’t get paid, saying thankyou is not only nice but is good encouragement for the authors to keep the project going.

Submit a Bug or Idea

Don’t like something about the way a product works? Wish it had a killer new feature? Don’t remain silent, instead head over to GitHub or CodePlex or wherever the project is hosted and create a new Issue or Bug “ticket” to tell the authors about it. Even if you think your idea may not be useful to other users, submit it anyway and let the project team decide.

Contribute Documentation or Design

Even if you’re not a programmer or you don’t have time to submit code to the project you can still help. There are some great open source projects out there, unfortunately sometimes the documentation for these projects is either non-existent, out of date, or lacking. Helping to make better documentation is a quick win for everyone.

Another contribution you can make is to the project design. Maybe you’re a graphic designer or know someone who’s an artist. Help the project team out by designing the project website CSS or by contributing a logo design. A lot of projects have limited time and so focus on the code, they don’t have time for design and logo-making. This is a great non-coding contribution to make.

Contribute Code

Contributing code to open source projects is a great gift of our valuable time and keystrokes. We can make the products better for ourselves and others. It’s also a great opportunity to learn.

If you’re running an open source project consider creating a label for easy issues/bugs/work items that a newcomer can tackle.

Create a Project

This is a biggie. If you’ve got an idea for a project, go for it! It’s super easy to get started on GitHub or CodePlex.

SHARE:

Introducing InAppPurchaseToggle for Windows Store In App Purchase

I just released version 2 of a new open source project called InAppPurchaseToggle.

It simplifies querying if the current user has paid for a particular in-app-purchase (IAP).

It’s convention based and allows creation of strongly-typed objects to represent each IAP offer that you’ve configured in the win8 dev dashboard for your app.

How To Use (updated for v2.0.0)

Create a new Windows Store app project (C#/XAML)in Visual Studio.

Install the NuGet package InAppPurchaseToggle.

Currently the package just installs the source in a folder called “InAppPurchaseToggleCode”, this is to simply multi platform (ARM, x86, x64) until NuGet is able to provide dll versions for different platforms.

Single In App Offer

Assuming you had set up an in app offer in the developer dashboard for your app called “AwesomeFeature1” you would create the following class:

internal class AwesomeFeature1 : InAppPurchaseToggle.SinglePurchaseToggleBase {}

There’s no need to implement anything else. Note: the name of the class exactly matches the name of the offer that was created in the developer dashboard.

More...

SHARE: