Withdrawing From the Echo Chamber and Clearing Mental Clutter

Updated 14 April 2016

I think I read too many blogs, follow too many people on social media, and get news from too many sources.  Perhaps you do, too

I know that Scoble is legendary for keeping up on umpteen jillion blogs, but even with the aid of feedreaders (are those still a thing?), it’s daunting.  And there’s just no payoff.  In fact, I am beginning to believe that being too connected to too many inputs actually is a negative.

There is a limited amount of overhead that the human brain can sustain and still be highly productive
I believe that every feed I follow, every blog I read regularly, every bit of connected-ness I currently have to various destinations in the tech echo chamber is like a lead weight, slowing down my brain.  Furthermore, I’m not convinced that being this highly connected to the industry is even healthy.

There’s too much focus on what the other guy is doing. Which designer has a clever CSS hack this week? Which company is launching what web app with no revenue model this week? Which Microsoft/Google/Apple technology (which obsoletes some other Microsoft/Google/Apple technology) is on the drawing board this week? Who’s making a billion? Who’s losing a billion? Who has mind share? Who’s leveraging the Long Tail? Who’s reached the Tipping Point…ugh.  It’s as though everyone who writes or reads a tech blog have all actually agreed to bullshit one another, and act like it’s all perfectly normal.

Guess what?  I don’t care about your web app.  I don’t care about the latest developer technology MS is working on.  I don’t care about the 19-year old whiz kid who just sold whattimeisit.com to Yahoo for a billion.  But by being so plugged in, I have sometimes managed to fool myself into thinking I care about these things.

What I do care about – passionately – is profitably solving problems for my clients.  Being overly connected distracts me from that. So, I’m going to opt out for a while.  Clear out the awareness baggage.  De-program.  And, thankfully, focus my mental bandwidth on how to continue effectively and profitably solving client problems.

I’ll continue updating my blog, of course.  And I’ll still be (somewhat less) active on Twitter; in fact, if you haven’t noticed, I recently reduced my following count by almost half. Being less connected will probably mean that what I write will be more informed by what’s happening out in the real world where software is used to keep real businesses running than by the online chatterbox where the focus is on who’s doing what.

Are you feeling like it is time to clear out the attention clutter and cut back on your connected-ness to the blogosphere too?

The same goes for the hundreds of items in my bookmarks.  All that takes up mental bandwidth, keeping the idea in the back of my head that all those bookmarks are there for a reason and that I have this hovering obligation to go back and look at them again and possibly DO something.  But really, those bookmarks just sit.  So I deleted every single one.  Now, I’m going to have to re-create a few, because they were for things like client websites and such, but the point is that if it doesn’t get re-created during the course of my work, then I didn’t really need it.

I’m also deactivating my accounts with online forums and 2nd-tier social networking sites (Snapchat is a good example; I tried it & it didn’t have anything I want, so now it’s gone).  Again, just having those accounts forms a sort of mental commitment to visit them, keep up with people, keep abreast of the latest, and feel obligated to DO something that doesn’t necessarily help my productivity.

Basically, if it’s not helping me to secure or complete projects for my company, if it’s not helping me to make money, if it’s not improving my life in some way, it’s mental clutter and it’s out.

So You Want To Be A Software Consultant?

So you want to be a software consultant, eh? I hear “how do I get into the business” questions a lot. I suppose I could save this for my next Monday Consulting Questions article, but I think I’d like to finish the month with a bang. So, let’s talk about it today.

There are several things I think you need in order to launch and have some assurance of success. Note that this list is by no means conclusive, it only represents the things that occurred to me in the shower this morning.

Experience. Ideally, you’ve been developing software professionally for at least 5 years, with steadily increasing responsibilities. You want 5 actual years of experience and growth, not 1 year of experience repeated 5 times over. But wait, there’s more. Hopefully you’ve also been able to spend about a year as a Team Lead or in some other position that lets you work at a slightly higher level, learning to manage people and allocate workloads. It would be super super ideal if you managed to get some project management experience too. In fact, I’ll go so far as to say that when launching a software consulting business, being a good project manager will be at least as important as being a good coder. If you don’t have any project management skills, be prepared to learn some.

Humility. Just because you’ve been a dev for 5+ years does NOT mean that you know it all. Preferably you’ve made some serious blunders, learned from them, and done better the next time a similar situation presented itself. If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.

Wisdom. Read these: Peopleware; The Mythical Man Month; Code Complete; Under Pressure and On Time Project Planning, Scheduling and Control; Slack; The Art of the Start; Book Yourself Solid; Million Dollar Consulting; Influence; The Time Trap; The E-Myth. Don’t argue, just read them. Read them all. Then read them all again. You don’t have to agree with them or even do what they tell you to do. But you do need to read them.

Contacts. When I say contacts, I’m talking not just about people you know, I’m talking about people you know who can be of help to you in launching your firm. People who can hire you for project work. People who can introduce you to other people who can hire you for project work. People who like you. People who want to see you succeed. People who will benefit if you succeed.

Clients. I can hear you already: “Well, DUH, Christopher.” But bear in mind that when I say you need clients, I’m saying that you need clients BEFORE you launch your firm. Don’t form a corporation, rent an office, buy computers with fancy 20" dual LCDs, hire a staff of 5, and then try to find clients. Oh no. Get yourself a few projects first, THEN launch. Deposits for several projects can make for decent start-up money. Work your network of contacts to find your first clients before launching your business.

Money. I’ve heard it said that professional services (like software consulting) are the easiest type of business to bootstrap. This may or may not be true. There’s another saying, though, one that I particularly like: always be prepared. Try to have as much of a financial cushion as possible before you launch.

A Team. Now, this is going to be controversial, since there are plenty of successful one-man operators. In fact, I used to be one, and even argued with Joel Spolsky about it. But the fact of the matter is, the sooner you are able to start delegating work, the sooner you can spend time working ON your business instead of working IN your business (kudos to The E-Myth for that saying). Working ON your business means you are building a system for doing business that will work even if you’re not actually billing. Basically, having a team means that you don’t have to do ALL the billable work. Starting out you will likely not be able to hire employees full time. Find some trustworthy subcontractors (former co-workers seem to work best) to begin with and make actual hires once you’ve fattened up.

Nerves of Steel. Launching a business of any kind is tough. When you’re just starting out, you can’t just code. You need to do your own books, you need to sell, you need to write the proposals, take out the garbage, negotiate the lease on your office, pay the bills, serve as technical support, beg your creditors for extra time to pay bills, and oh yeah, you might even write a little code from time to time. Clients will abuse you, they will slow-pay you, they will change their minds twice daily about what it is they really want you to be building. Cash flow will ebb and flow sharply sometimes. You may experience the rush of feeling like you hit the lottery one month, then the despair of feeling near bankruptcy the next. Of course, all of this can be managed, but you probably won’t know how at first. If uncertainty is emotionally difficult for you to deal with, re-think launching a firm.

I’m sure there is more to launching a software consulting firm than what I’ve laid out here. In fact, I know there is. However, I’m not going to be able to think of it all in one sitting; it’s a strange and varied universe we live in, and there are plenty of things that can make your consulting experience very unique.

If you would like to suggest additional requisites that belong on this list, go ahead and leave a comment.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

On Functional Specs and Project Pitfalls

Revised on 13 May, 2015

I found a good post about functional specs when I was reading Ian landsman’s blog this morning.  Ian notes the different opinions on whether or not writing functional spec is a good idea – one camp claiming that spec is purely a political appeasement move, and the other claiming that  spec is vital to a well-written app – and ends up coming down on the side of those of us who write functional specs.  Good show, Ian!  He also wisely notes that functional spec is best done in small bits.  I agree – the bigger a single iteration of spec is, the more likely it is you missed something.

There is a reason that I included inadequate/unclear requirements amongst The 5 Pitfalls of Estimating a Software project – this problem is HUGE in the industry and it cannot be solved by saying “specs don’t work – don’t write specs.”  It’s true that ultimately you need people to agree on the functional spec, just as it is true that they eventually need to agree on a user story or an interface mock-up.  This doesn’t not make the functional spec an appeasement document, though.  If anything, the process of developing a functional spec should get people talking about – even fighting about – what task experience the app needs to provide.  The biggest fear a developer has is to deliver an app only to be told “that’s what I asked for, but it’s not what I want,” and the process of developing a functional spec – done correctly – will avoid this. That’s why I’ve always advocated that every project needs at least – dare I say it – a small spec.

Having said that, I’m going to leave this here:

SmallSpec - painless functional specs

SmallSpec – painless functional specs

Ahem.  Moving on…

Why did I qualify my previous statement with “done correctly?”  Simple – too many developers have an “order taker” mentality when it comes to developing a functional spec.  A client or project manager will rattle off a list of wishes – “Yeah, this program needs to cure cancer, gnarfle the garthok, walk my dog, do my taxes, and make me a sandwich.  It’s pretty simple, you should be able to do it in about 2 hours.”  Now, at this point the developer can go one of two ways:

  1. Say “yes, sir” and shuffle off to make a half-hearted attempt at doing what he knows is impossible, only to be driven to drink and beat his children when hopelessness finally sets in, or
  2. Push back on the client or project manager, challenging their demands; “no, that doesn’t fit in-scope (unless we make adjustments elsewhere in the project)

I’ll give you three guesses what a good developer will do.  😉

When developing a functional spec, it is your obligation to act in a consultative fashion and challenge your clients assumptions and requests.  This is not McDevelopers – you don’t simply serve up whatever the client in the drive-thru orders through the speakerbox.  It is your job to protect the client from himself.  If you find that even after developing a functional spec, the delivered app is met with “that’s what I asked for, but it’s not what I wanted,” then odds are you have failed your client in some way.  Note that I did not say the spec has failed – you have failed.  Perhaps you didn’t probe deep enough.  Perhaps you let some assumptions slide.  Perhaps you didn’t lay out the different scenarios your client’s requests could lead to clearly enough.  I’ve been there, and it is painful to not only let your client down but fall flat on your face with your release.

Controlling scope creep is also part of doing functional specs correctly.  One can claim that functional specs inherently lead to scope creep because it is easy to add something to a Word document, but I disagree.  I think weak developers lead to scope creep.  Again I say – a good developer will not allow this to happen.  A good developer will push back.  “This change conflicts with xyz” or “This change will double the cost of abc” or “This change is not technically feasible,” etc.  When it is obvious that the scope of the project is in jeopardy of changing, a good developer will speak up and offer suggestions.  In some cases, the developer must be willing to stand firm and say NO.

Functional specs don’t fail.  Developers do.

To be fair, the “don’t write functional spec” guys were primarily designers at the time, although over the years they’ve built one hell of a software empire, and presumably still don’t believe in functional spec.  Even so, a designer is dealing with a different set of concerns than a developer is.   I get the impression that some people have a mental image of a functional spec that is just a massive, Steve McConnell-style Word doc with endless bullet points and no interface examples.

This is not how I do my specs here at Cogeian Systems.  Rough wireframe UIs are always liberally sprinkled throughout my functional specs to illustrate what the text is describing.  However, I don’t go into tremendous detail in the spec, nor do I go off building a real, functioning UI until it has been decided what that UI should do, and how it should do it.

A good functional spec should get you on the right side of the 80/20 rule.  Given that, it’s natural to allow for some discovery-as-you-go. And as you make these discoveries, your spec should become enlightened as you do.

I will stick with the approach that has made my projects successful – committing the application experience from a user POV down on paper in an appropriate level of detail in the form of a functional spec – and vetting it with the users – before writing a line of code or building a working interface.

The 5 Pitfalls of Estimating a Software Project

Updated June 27, 2016

People often ask me why estimating a software project is so fraught, why software projects are chronically late and/or over budget. Naturally, I always take that question as an opportunity to brag about my current level of skill at estimating projects.

It took until I was 6 years into my career to learn the art of estimating a software project so that it was acceptably accurate.  Along the way I discovered a set of behaviors that always lead to blown estimates and broken budgets. Avoiding these pitfalls will put any organization on the road to more accurately estimating a software project.  This will lead to happier clients and profitable projects.

Before we get started on the list, I want to make one thing clear:

Estimating a software project well is hard.

Know-it-all articles that tell you “just do this and everything will work out!” annoy me, and they probably annoy you, too.  Prefacing any kind of advice-giving with “just” is reductive and unhelpful.  Understand that what I’m offering you here are my particular experiences, offered in the spirit of “maybe try this?” rather than “just do this!” – because I acknowledge that what we’re trying to do when we develop estimates is hard.  In other words, these 5 pitfalls have been true for me and for the teams I’ve worked on, and I suspect they’ll be true for you too.  Ultimately, it’s up to you to try to fit them to your experiences as a developer and see if they work for you.

All that said, here are the 5 behaviors that I’ve seen consistently contribute to bad estimates:

1) Allowing non-technical staffers to give estimates.

You think I’m about to launch into a typical software developer’s tirade about how talent-less the people on the “business side” of the house are.  I’m not a typical software developer, though.  I value the business side of the house as much as I do the engineering side.  That said, a non-technical employee estimating a software project makes no sense.  You wouldn’t allow a software engineer to commit the company to a marketing plan of his own design, would you?  Of course not. Despite this, non-technical staffers giving technical estimates happens all the time.

To be clear – NOBODY should be estimating a software project except for the person who is actually going to perform the work.

Specialize or Die

Remember Adam Smith? He wrote an little book entitled The Wealth of Nations, maybe you’ve heard of it. In this book, he argued for the specialization of labor, using a pin factory of the day as an example:

…where each of a dozen workers engaged in only one part of the process of manufacture, so that together they produced far more pins than if each worker produced whole pins; the price of pins then fell, and more pins could be used by more people.

When businesses violate the principle of specialization of labor with regard to creating their product, trouble is soon to follow. It is far better to allow the specialists to do work that falls within their specialty than it is to placate a client by giving a totally fictional estimate.  Estimating a software project is specialized work, and should be treated that way.

Be Graceful Under Pressure

Because of the Iceberg Effect, a salesperson out in the field (assuming you work for an org large enough to have salespeople out in the field), who is under great pressure to close deals, is likely to think “Well, that’s just a couple of screens and buttons, it shouldn’t take very long“.  So the salesperson gives the client a number, and the number may as well be 1 hour or 1 million hours, because it cannot possibly have any connection to reality unless it comes from the person who has to build the thing being estimated.

Let your salespeople sell, your marketers market, your executives execute, and your developers develop…estimates, that is.  If you happen to be a small shop where people wear multiple hats, that’s just fine so long as the person who has to build it is also the person providing the estimate.

2) Being afraid to look in the mirror.

Most development shops I’ve interacted with do not do any “post-mortem” reviews at the end of an over-budget, past-due project (or even a successful project, for that matter). Therefore, they never learn what went wrong, never disseminate information that can other staffers avoid what happened, and thus promptly repeat the exact same mistakes. This causes the next project to be over-budget and past-due, and that project doesn’t get reviewed either, so the same mistakes are made on the project after that, and so on. Even seasoned developers can fall into this trap.

Don’t be afraid to take a look in the mirror and ask “what did I do wrong?” – this applies to everyday life as much as it does to software development. Always analyze your projects for both mistakes to correct and best practices to carry forward. Failure to do so is the equivalent of flying a 747 without visibility or instrumentation through the Himalayas; way too much risk for most client’s tastes (and checkbook). And again, if you’re a small shop without much in the way of formal review processes, take notes as you go; all you have to do is document the things that went poorly, and the reasons why.  When estimating a software project, having this kind of info at your disposal will help you create a better, more accurate estimate of the work to be done.

3) Underestimating design time and debugging time.

Many software developers are not in tune with The Business, they are in tune with The Thing – that is, they focus tightly on the act of construction and sometimes miss the other, equally vital, things that go into a successful project. In my experience, design is one of the most commonly underestimated things.  Yes, I just said that only the person who builds the thing can estimate the thing, and that counts for design work, too.  This is why it’s important for design and dev to work together when estimating a software project, rather than being silo’d away from each other or, even worse, being actively at odds with one another.  I’ve seen it happen in some dysfunctional orgs, and it is as ugly as it is counter-productive.

Figuring out how to build something takes more time than it took to figure out what to build. On the other end of things, debugging and refining and polishing up the code takes more time than anyone ever anticipates – in fact, in all my years in this business, I have never seen an accurate debugging estimate when estimating a software project. Never. Not once – not even my own!

Budgeting 50% of total development time for debugging is absolutely reasonable, if not necessary. Any developer who fails to accept this is still in the Age of Unlimited Wisdom (more on that later).

4) Inadequate/unclear requirements.

Before estimating a software project, you have to do some requirements-gathering.  There are many ways to do this, but gathering requirements at all is difficult. Gathering requirements well is rare, and gathering requirements in the correct quantity and level of detail before asking a developer to start work is just this side of miraculous. I would estimate that 90% of my pre-consultancy projects suffered from inadequate requirements.

Developer vs Analyst

Every developer has war stories about dealing with unbelievably poorly-written specs.  Every developer has war stories about requirements with more holes in it than Swiss Cheese.  Most developers like to blame the Business Analyst for this.  To be fair, most Business Analysts have war stories about OCD-affected developers.  Stories abound about devs who suffer from analysis paralysis without impossibly perfect specs.  That’s just the nature of the beast sometimes.

It is tempting to rush the requirements gathering process. It is tempting to just assume the answer to questions that are not addressed in the requirements. Mapping a client’s business process is hard, and very few people want to do it – those that actually relish the task are of a rare and strange breed. Uncovering and documenting every relevant hidden nuance of how a company operates is difficult.  This is why estimating a software project is difficult – it encompasses other things that are difficult.

Satisfying the Stakeholders

It’s downright hard to ensure that the high-level details are an accurate representation of what needs to be built. Inaccuracies will creep in if you let them.  This is doubly true if you are in a rush.

By slowing down – just a little bit – and making sure that the requirements gathering is done right (as in, not too detailed and not too vague) before construction begins, everyone will end up happier and the project is infinitely more likely to be a success.

5) Taking too large a bite from the apple at once.

I cannot count the number of times I’ve watched in horror as a Project Manager approached a junior programmer, asking “How long will it take to do X?”, only to hear “Not very long – maybe Y hours” in response from the young know-nothing.  My horror, you’ll note, stems not from the fact that the junior developer was a know-nothing (we all start someplace), but rather from the fact that the Project Manager should know better than to put a junior dev on the spot for something like that.  It’s bad for estimating a software project, it’s bad for whatever downstream politics the project is likely to run afoul of, and it’s exploitative of the junior developer.

Finding the Right Side of the Line

Regardless of what feature X might be, there’s only one correct answer to “how long will it take?”.  That answer is, “Let me see the requirements”. If you don’t have requirements, you need to get some, even if they’re super-lightweight. Even then, you can’t commit to anything better than a “plus or minus 50%” estimate until everyone has agreed that the requirements are on the right side of the 80/20 rules in terms of accuracy. Even then you cannot start estimating a software project until you break down those requirements down into bite-sized chunks.

Making Your Project Chunky

That, my friends is the secret weapon of estimating a software project – the more atomic you can make the requirements, the more accurate your resulting estimate can be.  This is why I love user stories – they’re super atomic (maybe too atomic for estimation purposes, but we can argue about that another day).  That said, the truth is that most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again – very few people want to do it. Those that do will consistently deliver more successful projects than those who do not.

I’m not saying anything here that people in the industry don’t already know. But I am saying a lot of things that people in the industry don’t do. I wish that were not the case, but I can only control my own projects.

 

Photo Credit: Luis Fernández García (license)