Peti's Braindump

Are you in the software business? Are you a programmer? A tester? An analyst? A product owner? Wouldn't you like to work in a project with the best possible setup? In a AAA software project?

But hey, what's a AAA software project? What makes it an AAA or a simple A or a B project? There's no such rating system in the software business like in the credit business. Of course, there are other software project rating systems like CMMI from the Carnegie Mellon University.

A much easier approach for checking the setup of a software project is the Joel Test (slightly outdated), containing a simple list of 12 points with things like version control, daily builds, having a bug database, etc. These are things every programmer has heard of or uses everyday. A while ago, I asked the readers in a Google+ post about what they think is important in the setup of a software project. I discussed this topic also with my co-workers. Lot's of things were named, but we didn't find a satisfying answer.

In the eleven years as a professional software engineer, there was not a single project or company using CMMI or any other project rating system. Of course, the projects and their setups evolved to this or that direction. We identified problems and made plans to fix them. To whatever conference I went, I discovered new practices which I didn't know and weren't used in my current project. Of course, me and my collegues wanted to apply them in the current project and the discussion started! When? How? Costs? ...

The thing is, I never knew if the current project was a BBB or a A or a AAA project. There were lots of good things, lots of things with potential for improvement... but no clear overview and no sexy term attracting people.

I like the AAA term because it is as catchy as the term "clean code". Everyone wants clean code! Few programmers I know were really interested in e.g. the liskov substitution principle (LSP), but everyone wanted clean code. But hey, LSP is part of clean code, so you'll have a look at it if you learn clean code.

So, enough bla bla and introduction. Let's try to put some things into a list, which I consider helpful for a software project:

AAA

Continuous delivery through one click with at least one productive deployment per day, without interrupting the users

AA

Applying design principles like SRP, OCP, LSP ... as for example described in the Clean Code book

Pull-based workflow like Kanban letting people solve tasks which they are really interested in

Having some kind of executable specification (e.g. BDD) allowing seamless development

A

Using design- and architectural patterns

Having a clear and documented software architecture

Continuous integration with automatic build and test of the software after each check-in

Working some kind of agile and shipping a release every 1..3 weeks

BBB

Having automated unit tests, integration tests and acceptance tests

BB

Having automated unit tests and integration tests

B

Having some kind of automated tests

Having an issue tracking system for new features, bugs, change-requests

Having a solid financial funding for the project

CCC

Using a version control system like git, mercurial, subversion, ...

CC

...

C

...

D

...

Thank god, I named my blog "Peti's Braindump". This is just a brain dump, too. The topic of the software project rating system seems to be quite complex. I think the different aspects from above should be better grouped, the items probably moved up or down, additional practices added, etc.

I gave it a try using this Google spreadsheet:

Feel free to change the spreadsheet. To extend it. To move things around. To delete things. Let me know, what you think! Google will keep track of the changes.

This morning, I had an interesting discussion about legacy software. Does the company we work for produce new legacy software, right now? As company, we improved in the last years our skills, our processes, our infrastructure, our architecture, our test coverage, etc etc... So my first opinion was no. "But in five years time, someone else will say that the way, we build the software using maven is legacy". And the discussion started!

Pretty soon, we found, that we don't have the same idea of what legacy software is.

One guy stated, that this is just code without tests (as also Michael Feathers does in the introduction of his broadly known "Working Effectively with Legacy Code" book). "But that's not the complete truth, in 20 years our java code with plenty of tests will be legacy", I argued.

After discussing this topic with my wife - she's NOT a software engineer, this helps! - I got some more insight about it.

So... my try to define the term legacy software is the following:

"Legacy software is software, which is not built according the way, you would build it right now."

Legacy is something very subjective. For one team, a particular piece of software is fine, for the other team, it's legacy. That's why I chose "..., you would...".

It's not only about having or not having tests, it's about "... the way, you would build...". For example, you are following the clean code practice and value the single responsibility principle (SRP). For me, a codebase with lots of tests but broadly violating SRP is legacy, too. Or you are using a relational database together will a home-made persistence-layer. This persistence layer could be legacy for someone, who prefers JPA (Java Persistence API).

So, the term is clearly defined now, isn't it!? ;-) But when is something becoming legacy?

"Sooner or later everything becomes legacy, and becomes then not legacy."

So, I hope that the stuff you write right now is not legacy and you do it according the way you / your organisation want to follow. But I'm sure, one day it will be legacy because you / your organisation took a different way, for example using JEE instead of Spring or Ceylon instead of Java or whatever you think is better than something you have used before.

But, no worries. One day your software will be completely replaced with an other software and finally be not legacy!

Last Monday, I discovered Uncle Bob's new website cleancoders.com with an interesting business-model. Uncle Bob is trying to sell his learning videos, code-casts.

For me, this was a new idea: New kinds of learning content for cash.

Also on last Monday, Dan Allen did a Google+ post asking for a clever name for a new JBoss community special interest group to build up a knowledge base for JBoss / JEE stuff like tutorials, examples etc...

As a software developer, I really appreciate this content. Whether it is a good tutorial, a Github example project, a video from a good speech at a conference somewhere,... whatever helps or inspires me. Thanks folks, for sharing!

Usually, this content is for free

Usually, it takes some time to find the good stuff

Usually, I find a lot of "less useful" material, too

Sometimes, there is no good stuff at all

The problem is in my opinion: It's hard to make your living with learning content. Why isn't there more excellent, low-priced content? The typical commercial content carriers like books, classroom courses, conferences are hard to make. Looking at books, the ebook-technology helps a lot, but how to promote and sell it on your own? Looking at videos or screencasts, they are also not really hard to make (technically), but how to promote and sell it on your own?

Enough introduction, let's talk about the LearnStore idea.

LearnStore

What

Like an AppStore (Apple / Android / ...), but with learning content like e.g. Uncle Bob's Clean Code Video's, JBoss Arquillian in-depth tutorial, Spring Roo screencasts, etc etc... But of course, not only software stuff... Gardener know-how, car fixing videos, etc etc...

Features could be: User rating, suggestions, content-of-the-week, what's hot, etc etc...

Pricing would be per content item: e.g. a Heinz Kabutz Javaspecialist screencast for 2$, an Uncle Bob codecast for 2$, a recording from the JavaOne 2011 keynote for free,...

Who

The typical content creator could be: OpenSourceSoftware organisations, independent software craftman's, students, any experts, you, he, she, ... Win-factor: Earn something with your work

The typical content consumer could be: professional software developers, students, classroom course providers looking for some add-ons, you, she, he, ... Win-factor: Get good content for few bucks or even for free

The typical LearnStore provider could be: A commercial organisation, a non-profit-organisation, a cooperative, ... Win-factor: Earn something with providing the platform

Why

Today, from a commercial viewpoint, the learning content is probably just a door-opener (get hired as consultant, make your classroom courses popular,...), or an advertisement-magnet (AdSense, ...) or a checkbox on a checklist of a product. Why not make directly money with it?

Being able to sell learning content in an easy way will attract people to create new content. Content rating by users helps content quality.

Lots of new high quality learning content improves the world, doesn't it!?!

How

Website

Consumer device app (tablets, smartphones, ...)

Processes (billing, content verification, refunds, ...)

Making the LearnStore popular

Does it exist, already?

As far as I have seen, there is no such model alive. For me as a software developer, I found

parleys.com, subscription based

learnable.com, subscription based

Uncle Bob's cleancoders.com, priced per content item (great), but only 8 items... and expensive.

But hey, usually Apple invents these things?! And so they did. On January 19, there was an apple keynote "apple education event" where they unveiled their new interactive textbooks, iBooks author to create the textbooks and iTunes U app (U = University) for complete courses. As far as I can see, they cover all the stuff from above... and much more! Watch the keynote, it's amazing.

I'm pretty sure, Apple will revolutionize education.

Summary

Last Friday, I read an article from Cal Newport with the title Getting Creative Things Done: How To Fit Hard Thinking Into a Busy Schedule.

Basically he enhanced the idea of Block out time on the calendar for big projects with

focusing on process, not on goals in these blocks

working on only one (max two) project(s) in the same week in these blocks

zero interruptions in these blocks

...

which was quite interesting.

My recent, personal findings in the area of regaining / keeping the creativity are the following

Humans are creative by design

If you're not creative, eliminate your creativity-blockers

In my life, I found the following creativity-blockers

Over-packed TODO lists

Engagement for solving other people's problems

Lots of promises made

As soon as I

Cleared my email inbox

Cleared my desk

Cleared my whiteboard

Cancelled my promises

and learned to say NO

my creativity was back! Once I had it back, I couldn't remember when it was gone. Long ago!?