Developer Playground

Here are a few valuable sources of information to learn more about Technical Entrepreneurship in general:

The Lean Startup by Eric Ries

Effectual Entrepreneurship by Stuart Read (and others)

A Whack On The Side Of The Head by Roger Von Oech

Stanford Online Entrepreneurship Course (https://novoed.com/venture1-2014-2)

PluralSight course - "So you want to be an Entrepreneur" by Dan Appleman.

It is often helpful to create a low fidelity mockup of a UI page - a wireframe. Or else, add some visual markup to an existing image or wireframe.

Two tools that can really help out here are:

Balsamiq (https://balsamiq.com/)

Skitch (https://evernote.com/skitch/)

Both are really easy to get started with, and will quickly allow the user to mockup wireframes or images of real websites with editing of widgets and commentary markup.

To get up to speed with Balsamiq, I would highly recommend:

Came across good reminder this week on the value of TDD / BDD done correctly. Anyone who has practiced TDD has likely fallen victim at some stage of the "refactoring hell" that occurs when your tests know too much about the implementation details of what is under test.  The premise of TDD is summed up succinctly by the mantra "RED GREEN REFACTOR". Write a test depicting the ideal API for the "behaviour" of the system you are seeking to create, see that test fail (red). Do whatever it takes to get that test to compile and pass (green). Refactor so the test still succeeds (green) but the duplication etc is removed. Triangulate with more tests to ensure hacks such as hard coded values etc are replaced with real logic.

Ok, so where did it all go so wrong. Essentially, TDD got misunderstood and for OO languages all classes and all methods in those classes ended up being written with accompanying unit tests - leading to highly coupled testcode - any small changes to the implementation details of the class under test, and there is test breakage. Furthermore, sometimes the test code (LOC) ended up far exceeding the actual application logic code. And the effort expended on writing and maintaining these tests in tandem with code changes can be a great cost to timely delivery of the system, and developer hours.

How to do TTD right? Consider moving to BDD mindset (and tooling, though the focus is not on tools). Do TDD the way it was supposed to be done - focus on the "public" behaviour that your application should exhibit, test just that and don't be so concerned with internals and implementation concerns. Throw away tests to aid the actual coding of the internals is ok, of course aiming to keep implementations as simple as possible. Think in terms of expectations rather than assertions.

Not "everything" needs a test, instead focus on the behaviour. That way, when internal implementations are altered, the tests still validate the behaviour but are not brittle and subject to failure all the time as implementation details get refactored. Instead, they should fail only when changes to the system result in changes to the behaviour of the application.

Been coding sometime now, gradually turning into one of the grey beards. Guess this is inevitable if you decide to remain a Unix programmer long enough.

Anyhow, not so frequent these days that something genuinely fundamental to our craft, really makes me stop and take notice. Had one of those moments this weekend and thought it might be worth sharing briefly.

Question: How many of you know for certain things like...

Total lines of code in your current application

Average lines of code in each source file in your application

Breakdowns (lines of code, lines of comments, lines of mixed, lines left blank)

Length of each function / method within source files

And more importantly:

How difficult it is to understand the code 

The mental effort needed to code a program 

The algorithmic complexity of code units. 

Using Javascript heavily for client and server side coding, this is a language that really benefits from using code quality tooling and best practices. 

One premise of trying to measure software complexity is that bug-laden code usually manifests itself in complex parts of the codebase. This stands to reason - complex components are also hard to understand, hard to test, and hard to modify. If we know where the perceived complexity is in our programs (or others programs for unfamiliar codebases) we likely get some ideas where potential bugs might exists.  If we reduce the program complexity, the programs will improve. In fact, practical experience has shown this to be true. 

There are two main concepts widely used for measuring code complexity today: 

Halstead‟s theory of software metrics has its roots in evaluating complexity of low level programs like assembly language. He proposed a short set of measurable operator and operand quantities and then used them in equations to predict program features. 

McCabe‟s model for software metrics determines the complexity of a program unit or module by measuring the amount of decision logic. The McCabe number is a predictive measure of reliability. In itself, the complexity value does not identify problems or errors but there is strong correlation between and code errors in studies conducted.

 Both Halstead and McCabe models are applied to real projects and are supported by commercial tools. The McCabe number is often also referred to as “conditional complexity” or “cyclomatic complexity metric.”

So what?

Well, I pretty much thought the same, but then installed 3 different modules for NodeJS and integrated with the DFM Build process -  that allowed me to measure the Halstead and McCabe complexity of my code, and provide some beautiful HTML reports in the process. I set thresholds (numbers, without getting too hung up on their meanings), Green, Yellow, and Red system.

The Results?

Were astonishing. With respect code, I knew where the “complexity” lurked, I had some inklings which parts of the code base should be revisited with further iterations to refactor stuff, which functions were too many LOC, etc etc. And the correlation between what I knew and what this report was able to spew out in a fraction of a second was really strong. It provides a score for overall how maintainable the code is, likelihood of bugs per function of file etc etc.

The moral of the story?