Tag Archives: agile

Granular Software Estimation is a Myth

Leave a reply

Software estimation has got to be one of the best examples of humanity as a whole not learning from its mistakes. Time and time again we attempt to estimate how long our software is going to take and it’s always always wrong; And usually it’s wrong by a lot. But we keep doing it.

Why Estimate at All? Can you?

icebergWhen time and money are finite it’s important to weigh alternatives. Usually the way this happens is we try weigh software X vs software Y in terms of what will have the highest impact per time input. But complexity determines time input. And you can’t understand the complexities of software and the variables involved because they do not become clear until you are in the middle of developing the software and uncover that complexity. At the start of a project our level of understanding about the software is the lowest it will ever be, which makes it the worst possible time to estimate.

So what do you do? How do we estimate then?

Software estimation is a lot like estimating nature:

  • You can’t accurately estimate whether a volcano is going to explode unless you are estimating within a matter of weeks.
  • You can’t accurately estimate the weather unless the estimate is within a matter of weeks.
  • You can’t accurately estimate where a hurricane is going to landfall unless you are estimating within a week.

What’s the common theme? Complexity. Nature is a very complex thing and as such the only way to estimate is to reduce complexity. The only way to reduce complexity is to reduce the amount of time that complexity can take place. Software is like that. Software is complex. If anyone tells you that anything in software development is simple they either haven’t been bit by this or don’t understand the complexity involved.

The only way to estimate accurately is by doing one of the following:

  1. Provide very low confidence very coarse-grained estimates.
  2. Provide estimates for things with low complexity.
  3. Provide estimates for things that are going to happen in the next week or two.

Items 2 and 3 are really just the same thing, stated in different terms. If you attempt to granularly estimate anything farther than a couple weeks out you are lying to yourself and everyone involved in your project. Item 1 is only valuable when it helps you make a significant decision about finite resources like time and money.

It’s been my experience that item 1 estimates are too tempting and can be abused, leaving item 2 and 3 as more attractive options. Don’t plan and estimate big software. Plan and estimate small incremental software.

The Backwards Monk

Leave a reply

A certain monk had an odd method of writing code. When presented with a problem, he would first write many automated tests to verify that the yet-unwritten code was correct. These would of course fail, as there was nothing yet to test. Only when the tests were done would the monk work on the desired code itself, proceeding diligently until all tests passed.

His brothers ridiculed this process, which caused the monk to produce only half as much application code as his peers—and even then only after a long delay. They called him Luohou, the Backwards Monk.

Java master Banzen heard of this. “I will investigate,” he declared.

Upon his return, the master decreed that all members of the clan who were done with the week’s assignments could accompany him to the swimming hole as reward for their efficiency. The Backwards Monk stayed behind, alone.

At the top of the diving cliff, the eldest of the monks peered over the edge and shrank back.

“Master!” he cried. “Someone has scattered the stones of the dam! The swimming hole is empty of water. Only weeds and sharp rocks await us below!”

With his staff Banzen prodded the youth forward towards the precipice.

“Surely,” said the master, “you can solve that problem when you reach the bottom.”

Source: The Backwards Monk

Android Development – Stack Careers

Leave a reply

I’ve been itching to get into Android development for some time now. I must confess my ultimate goal is to create games for Android, but I actually can’t do that right now for some reasons I won’t explain here (contact me privately if you’d like to know more). That’s ok though, because creating games is a more complex undertaking on a platform you’re not familiar with. I needed something to get my feet wet, so I chose to create something that is simple but still useful.

‘The Lean Startup’, a book by Eric Ries about how to create successful products and services, proposes a method for accomplishing that goal:

  • Leverage validated learning
  • Scientific experimentation
  • Iterative product releases
  • Measuring progress
  • Gaining valuable customer feedback

To accomplish this, the book defines a ‘minimum viable product’ (MVP). An MVP is “a version of a new product which allows collection of the maximum amount of validated learning about customers with the least effort.”

The general idea is that you should develop something extremely simple in quick order, put it out there, and use it to gain feedback early and begin successive iterations to improve upon it. The advantages are numerous, but most notably is this: If you spend a lot of time scheming and planning out a project and developing without releasing it for a while, you may end up developing something that isn’t quite what your customers want at best, and at worst is something completely useless and opposite of what your customer actually wants.

androidSo I decided to build an Android app that is really simple with limited scope so that I could get something out there that provides value early and is open for feedback loops.

If you’re familiar with Stackoverflow (I really hope you are if you’re a software developer) you may be familiar with Careers 2.0. It’s a job search site tied in with the Stack Overflow crowd. Unlike traditional StackExchange sites which have full APIs, this site has only a limited RSS feed for job seekers (there is no API for employer or resume/CV data, which makes sense given that it’s a source of revenue for StackExchange). I chose to make an app that leverages that simple RSS feed data.

Here’s what parameters this simple RSS ‘API’ supports:

http://careers.stackoverflow.com/jobs/feed
    ?searchTerm=ruby&location=seattle&range=20&distanceUnits=Miles

Given that this is my first Android project, I knew I needed to limit my scope as much as possible because a non-trivial amount of time and effort would actually be just in learning the Android SDK and development process. So to further limit the scope of the effort, I decided I would only implement the skill and location search abilities.

I learned all about Android concepts like activities, intents, and the lifecycle of such things. I learned best practices for network communication, xml parsing, asynchronous work off of the UI thread, and more. I kept a set of bookmarks and guides that were helpful to me along the way, with the intention of writing a blog post series on basic Android 101 development in the future (keep your eyes out for this soon).

48 hours of effort later I have a first iteration suitable for release. Behold, ‘StackCareers’:

Stack Careers Stack Careers

It’s nothing amazing I suppose, but it does one job and does it well (those Unix guys in the days of yore were on to something). If you check it out, I’d love your feedback and suggestions.

Stack Careers app on Google Play

Google Play is a trademark of Google Inc.

The Stack Exchange and Stack Overflow names and logos are trademarks of Stack Exchange Inc.

 

 

Code Is a Liability: Emotional Detachment From Code

Leave a reply

Sometimes a developer or organization will consider their code to be valuable. Is code valuable? I don’t think so. Code is a reusable and disposable resource. It’s also a liability.

A liability?

Yes because when you write code and it solves a problem, it is useful. But once the problem changes, it’s just bytes. And believe me, the problem will change. Then you’ve got more bytes to maintain. Code then is a liability and the longer it sticks around the more drag you’re creating on the future.

What if you spent a non insignificant amount of time writing code only to discover the problem you were solving has changed? Well hopefully if you’re leveraging an agile methodology that time period will be small, but if it’s not you’ve got to be able to throw away your work entirely. It’s easy to get attached to code that you’ve written and want to try and take it along with you like a boat anchor but you must be able to dump your code without a second thought when it’s no longer useful.

Recognize when code is adding value and when it needs to be taken out back of the shed. It’s not your code. It’s the code. Make sure it isn’t a liability.

How To Hire Great Developers

2 Replies

In a previous set of posts I talked about how the difference between an average developer and a great developer is enormous, how bad developers can effectively cancel-out your good developers, and why you therefor need to hire just the very best.

So how do you tell if someone is good? or bad? What are the core competencies and key indicators of an ‘A’ player developer? And how do you interview for them?

Great Developer Key Indicators

The following is a list I’ve accumulated over time. It’s never complete, and certainly up for discussion, but in my experience is a pretty good set of indicators for whether a developer is an ‘A’ player or not.

Great developers:

  • Can deal with many levels of abstraction simultaneously.
  • Are masters at managing complexity.
  • Know space and time trade-offs of the major data structures.
  • Understands multi-threading, resource locking, and how it’s implemented.
  • Understands that simple is better than complicated, every time.
  • Has used a DVCS (git, mercurial, etc).
  • Are masters at managing expectations.
  • Plays with new technologies and languages and stays aware of upcoming developments.
  • Understands what TDD is and why it’s a valuable practice.
  • Is likely to develop iteratively and incrementally, adding value with each release.
  • Understands how to accomplish loose-coupling and encapsulation, especially in things that are likely to change.
  • Is not a lone-coder who goes dark for long periods of time.
  • Knows how to communicate well, not just with developers, but all levels of management and stakeholders, and can adjust communication vocabulary/style per context.
  • Knows SOLID principles and practices them effectively.
  • Recognizes that code reviews are excellent ways to improve yourself, both as an author or reviewer.
  • Can grasp the bigger picture.
  • Doesn’t just accept work items and marching orders, but also proposes alternatives and improvements.
  • Knows 1 procedural language, 1 object-oriented language, 1 functional language, 1 scripting language, 1 statically typed language, and 1 dynamically typed language. (There is much overlap between these categorizations)
  • Fluent in major design patterns and how/when to implement them.
  • Knows most of these books:  Code Complete, Pragmatic Programmer, Clean Code, Mythical Man Month, Design Patterns by the Gang of Four, Programming Perls, Code: The Hidden Language of Computer Hardware and Software, C by K&R.
  • Keeps up with development blogs/twitter/podcasts.
  • Is highly passionate about software development.

Bad Developer Red Flags

There are some simple things you can do to immediately weed out the really bad developers in an interview scenario.

  • Have them write FizzBuzz; believe it or not most developers do poorly on this, and it’s a great way to identify them early on in the process.
  • Ask them what the last new language or development environment they learned was. If it’s been a long time since they’ve learned a new one, that’s a red flag.
  • Ask them what they think a great developer’s best attributes are. If the answer isn’t in the list above, it’s probably a red flag.
  • Have them explain dependency injection to you, and a simple example. If you get a deer-in-headlights response, it’s a red flag.
  • Ask them to solve problems that involve in-place manipulation of a linked list or string. If they don’t understand pointers or space/time complexities of a problem, that’s a concern. ‘Reverse a linked list’ is a good one to ask.
  • Find out if they have a GitHub/BitBucket/Codeplex/SourceForge.  Look for evidence of development both inside and outside of work.

What NOT To Do

  • Don’t ask questions that are just quick facts. A programmer that knows what port IMAP runs on isn’t going to be a better programmer than one who doesn’t. Knowing little C compiler optimizations doesn’t make you a better programmer.
  • Don’t just ask questions with verbal answers, or open-ended answers. Actually have them write code on the whiteboard. A lot.
  • Don’t use questions that are common enough to where they could be googled before hand or memorized.
  • Don’t just be satisfied that someone answered something correctly. Talk to them about their solution. Ask them to modify it. Ask them to test it. Challenge their thinking.

This is an organic post, and I suspect I’ll add many suggestions from readers.

 

Work Smarter, Not Harder

Leave a reply

During the industrial age it was common to hear people romantically refer to their work ethic by the incredible number of hours they worked. The calculation many people had in their minds was that working a ton of hours correlated to long term success. This actually made a fair amount of sense, given that if you put in N hours, you might be able to make N widgets, wheras if you put in N+5 hours, you could make N+5 widgets.

This Isn’t Manual Labor

Software development doesn’t work like that. It’s been a long time since there was a strong case made for equating more hours input with more success output. In fact, working with software is much more about working smarter, not harder. You can put in quite a small amount of hours done intelligently and get out a spectacular output of success. In terms of overall success, it’s usually a combination of elegant technical solutions married with great opportunities.

How It Relates to Agile

Many software shops that have historically been using a waterfall approach find it challenging to accept that 100% resource utilization isn’t valuable. It’s much more important to prioritize work, limit work in progress, and deliver working software early/often. Just because someone is freed up does not mean that we should stick them on a new project, because what you’ll end up with is just a divergence in the number of things you’re trying to accomplish. Ultimately this leads to a lack of focus, and a dilution of talent across too many objectives.

Related book: The Mythical Man Month