In order to answer this question, we need to understand the term “flow”. From Peopleware:

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.”  There is no consciousness of effort; the work just seems to, well, flow. You’ve been in this state often, so we don’t have to describe it to you.

Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It’s only when you’re in flow that the work goes well.

To paraphrase, “It’s only when you’re in flow that you’re at your most productive”.

The quotation is taken from chapter 10, page 65. I know that because after reading those short paragraphs, I realised something that made me stop and put the book down..

When a software developer thinks up an estimated time to complete a development task – they’re thinking solely in “flow” time.

That realisation is profound.

Sure, more experienced software developers will then add time to this based on their experience before giving their answer, but their first thought is based on flow-time, which is their best-case, uninterrupted development time.

Why is this?

I think it’s a combination of 2 things;

1. The question itself.. “how long would it take you to do / fix / add / change x?”.
   A developers starting point is their experience of development to date, and that development is at it’s most productive in flow-time. So they’re going to answer you based on them being in productive flow-time. However, this means they’re starting their estimate based on an unaware assumption that they’re quoting flow-time.
   For example, if a developer responds with “it’ll take me half a day”, what they’re really saying is “with a half-day of flow-time, I can do / fix /add / change x”.
2. If you didn’t already know, developers are optimistic. They’re optimistic about how much they can get done, and they’re optimistic about how much flow-time they’re going to have.

So what is the answer?!

To quote more from Peopleware:

Chances are, your company’s present time accounting system is based on a conventional model. It assumes that work accomplished is proportional to the number of hours put in. When workers fill out their time sheets in this scheme, they make no distinction between doing meaningful work and hours of pure frustration. So they’re reporting body time rather than brain time.

…

The phenomena of flow and immersion give us a more realistic way to model how time is applied to a development task. What matters is not the amount of time you’re present, but the amount of time that you’re working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won’t accomplish anything.

The answer, then, is to take the developers estimate with a pinch of salt (the more ’seasoned’ the developer, the less salt required), remember that their estimate is an estimate, and use it with evidence based scheduling (if you aren’t already).

The next question you may be asking of course, is how do I reduce the difference between the estimate and the actual – the ’slip’.

That’s a topic for another day. I’ll let you know when I’ve finished Peopleware, or you can grab a copy for yourself 

Recently, our little software company was contacted by a local college, to provide feedback on the content of a couple of new software engineering and advanced programming courses they are looking to run.

I saw this is my first opportunity to offer my assistance to those asking how should we teach software engineering?

Hi Iain, thank you for your reminder – please accept my apologies for not getting back to you sooner!

I’ve read the 2 course outlines you sent and I think you’ve got a good focus for students wishing to go on to develop software development roles. I like the outline of the courses very much – especially your choice of .Net as we’re a .Net-based development company ourselves.

If I may, I would like to suggest a few areas that I found lacking in my own formal education that I think, should a graduate make note of on their C.V. as having had experience of on your courses, would put them on top of the pile based on my experience of hiring developers at OnePoint Systems. These are, namely:

An introduction to source control
this could be as little as a single session describing what it is, why it’s essential in software development, release and maintenance lifecycles – without a doubt in team-based development, but it can also offer huge benefits for individuation development projects. I think it would be ideal to get the students to have hands-one experience with it – say as part of a team project, or as a requirement for handing in software for marking that it is checked in to some source control that the teacher would then check-out and build so as to mark

An overview of Agile Methodologies
I see you have R.A.D. and Prototyping listed which is excellent (as is understanding the Waterfall Lifecycle), but I’ve found in my professional development that Agile – specifically Test-Driven Development (TDD) is fast becoming commonplace in software development companies – to quote Steve McConnell (author of Code Complete): “within the next few years we won’t talk about Agile much anymore; we’ll just talk about programming”. I would not wish to cover this topic in any more detail as I assume you are already familiar with it

A lesson on 3rd party tools and controls
Something that I found completely missing in my formal education was (even the notion of) the practice of using 3rd party tools and controls within my own software projects. While tools could be covered by introducing source-control and add-ins for development IDE’s (such as Microsoft’s SourceSafe or Team System), or debugging tools such as Lutz Roeder’s .Net Reflector, the integration of 3rd party controls for their re-use value alone is, in my opinion, worth a session on its own – even if the students don’t get to actually use 3rd part controls. I’m thinking of listing a few resources such as ComponentSource.com, telerik.com, infragistics.com or janussys.com – to open the students mind to the idea that developing everything in-house is rarely the best way to proceed.

Reporting
for most application development a little hands-on experience about how software reports are put together is, again, in my opinion essential. The reporting engine, be it Microsoft Reporting Services, Crystal Reports or a 3rd party reporting add-in such as Active Reports for .Net is of little differentiating factor for the simple kind of reports that allow the students to get the data out of their software creations and onto a physical piece of paper. In many ways, I think report creation is the final, completing step in creating a software application – it’s the tangible output of an intangible product.

I thank you very much for this opportunity to offer my feedback, and I wish you and your students the very best. If I may be of any further assistance, please get in touch and I shall endeavour to be a little more responsive with my reply.

Kindest regards,

Andrew
–
Andrew Freemantle

I don’t think it would be appropriate to talk about Unit Testing without first starting with the bigger picture of Agile Software Engineering Methodologies.

I started working to the Agile methodologies, as described by Robert C. Martin about 18 months ago. It was hard not to see it as a ‘magic bullet’ that enables the production of quality software because it just made so much sense to me. Here’s Steve McConnell’s view of Agile development:

Q4: What is the future of Agile?
Agile has largely become a synonym for “modern software practices that work,” so I think the future of Agile with a capital “A” is the same as the past of Object Oriented or Structured. We rarely talk about Object Oriented programming anymore; it’s just programming. Similarly, I think Agile has worked its way into the mainstream such that within the next few years we won’t talk about Agile much anymore; we’ll just talk about programming, and it will be assumed that everyone means Agile whenever that’s appropriate.

I have emphasised Steve’s sentence that beautifully sums up Agile for me – ‘Agile’ is my definition of programming.

Changing my way of thinking from initially ‘where do I start coding the solution?’ to ‘how am I going to TEST the solution?’ was definitely challenging, but I still remember sitting down to start actually writing test code and wondering ‘how far should my unit tests go?’ – meaning, if I’m testing that an Object can persist, or save its state to a database, how do I test that it’s working?

My current project incorporates the excellent Rockford Lhotka’s CSLA.Net framework, and my first attempts at testing for persistence did so by reading the database tables to verify the data written – in the same unit test..

In practice, these unit test cases were well over a screen full of code which, when testing different scenario’s around the edit and save logic, meant I’d created an overhead that added a quite considerable amount of time to their maintenance when features were added and changes were inevitably made to the application code being tested.

I was already thinking about separating out the unit test code into it’s component parts to make handling change less painful, when I saw the title of Carl and Richard’s audio talk show “Dot Net Rocks!” #312 – “Andy Leonard on Unit Testing your Database”. Being a Database guy, Andy’s main reason for unit testing the Database is that we developers sometimes forget that we write code there, and that our Database code is as much a part of the application – but I think his rationale also solves the maintenance issue with my single, large unit tests..

By separating out the unit tests to check the Database layer, it massively simplifies the readability and maintenance of the application layer unit tests. Moreover, if you locate the Database layer unit tests in their own library, then they can be executed before the application layer unit tests so they can halt further testing as it’s highly likely that failure at the lower database level will manifest itself higher up. This will ultimately save us time locating and fixing failing code, as well as saving time modifying existing unit tests when changes occur.

It was drummed into me throughout my software engineering training years – the essential internal documentation of software – the comment.

After a few years actually engineering software, I’ve found that I can categorise most comments into 4 basic types:

1. The obsolete code block, often with an accompanying note about why it was removed or replaced
2. The overly-verbose or overly-descriptive, highlighting the obvious
3. The reference; a Bug tracking reference number or URL link to where the block of code originated
4. The one or two-liner descriptive, concise explanation

And having done so, I have found that the first 3 are actually detrimental to the process of maintaining or otherwise changing software. Let’s look at them in closer detail to find out why..

1. If we’re using any decent form of source code version control, then there is no benefit whatsoever to leaving commented out, obsolete code blocks in the software – in fact, I’d argue that when following a thread of logic through function to function, having to skip over comments that look like code is actually detrimental to understanding why the code does what it does. Consider that source control makes it a trivial task to compare or replace the current code with any previous checked-in version of the code, and there simply isn’t a sensible reason to leave old code in place.

2. I take this to be an indication that there is no accompanying documentation, or it\’s going to be sparse at best. If it\’s a block comment about why a particular feature exists then a better place for it is in some form of requirements documentation; if it’s a block comment about a design decision then it would be better placed in the design documentation. Any other documentation format easily wins over plain-text descriptions, and designs are better illustrated, well, with illustrations.

3. I’ve worked out that both of the above are bad, yet I still catch myself thinking that it’s somehow beneficial to the maintenance of the code if I include a Bug tracking reference number next to the code I’ve changed. If I’m coming back to the code because of a problem with the fix I’ve made, then it’s much easier to search through the source code version control check-in comments for the Bug reference number than through the source code itself – if only because it’ll be a hell of a lot faster. If I’m in the code for another reason – say I’m adding something new – finding a Bug tracking number isn’t going to make me head off to the Bug System and look up it’s history.. I know what the code is doing because I’m in there reading it and stepping through it. URLs serve as a similar distraction from the actual workings of the software. That said, I think URLs are useful in referencing the origin of an entire Class, algorithm or Library.

4. The most helpful comments I’ve found are the concise, single-line description of what’s going on that help keep the reader on track – such as what we’re looping through or why we’re looping when we’re 2 or 3 Arrays deep. Like breadcrumbs, they assist you and your maintainer in un-ravelling the mystery of your software.

I’ve found that putting as much thought into the content of my comments, as I do into the content of my code, makes it much easier to maintain my software.