Your developers aren’t slow

- nonexistent or substandard tools

...including old compilers and otherwise a lack of support for the compilers, debuggers, editors, analyzers, profilers, etc. that will enable a developer to focus on business problems instead of technology stack problems.

  - waiting for regression tester

Or worse, a lack of regression testing requiring substantial software archaeology in order to be confident enough to make a change to legacy code.

Similarly:

  - substandard documentation

- reinventing the wheel because a perfectly serviceable existing solution cannot be licensed

I can't stand hearing that there's no room in the budget to pay a flat $500 to license a 3rd-party grid control (for example) only to have a $90k/yr salaried developer spend 20 or more hours recreating barely a tenth of its features. It's even worse when the license is free (as in speech), but it still can't be used, because the code hasn't been blessed by the security department, or because management simply has a prejudicial bias against the terms of the LGPL.

If a feature isn't tested, or proved useful to a user is it really progress?

- underpowered hardware

At my previous job I requested an upgrade from a 3 year-old laptop. Initially they approved it, but before ordering one they reversed and denied my request. The justification was they'd spent too much outfitting new hires and it was no longer in the budget, despite my request coming long before the interview process started for the new hires. To make it worse, the new hires were entry level and I had the second longest tenure at the company (~90 people).

Now I work somewhere that happily provides every technical employee with the latest maxed out hardware. The difference in amount of work accomplished is staggering.

Thanks!

I agree, there's a handful of these issues I'd planned on talking about in future posts; but your list adds a bunch more I hadn't thought of.

Lack of training is a tricky one, isn't it? If you give the wrong kind of training, or too much, or too little, it's easy to miss the mark.

Ed,

Can you elaborate on peer review and code review ? I have worked with and without these steps and can quantify the hours required and the quality shift in having these steps.

Do you think that these two can be disconnected from the development workflow with acceptable consequences? Or is it that there might be other standards or development measures which are no being met, such that there IS a need for review ?

I've found the hardest part is "build good software". Granted, I'm new, only going off of experiences in four internships. e.g. Now, this company is building a tablet application, except the director is serious about UX and hired actual UX people. But things are constantly changing, on a weekly basis; we'll build out some complex interaction feature, then then have it scrapped a few weeks later. And the codebase has suffered greatly.

Yes! I think this section of the post could definitely be expanded on:

It’s important to have developer buy-in. Their passion for a feature can be a huge driver for velocity.

This is why I also appreciate PM tools that incorporate discussion threads: that back-and-forth communication really helps clarify what you're building. I also like using the 5 whys after the initial spec has been written: "Why are we building this feature?"

> But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.

Yep. It almost sounded like this article was saying "you're not waterfalling hard enough". Processes are not a substitute for human interaction, they are supposed to enable human interaction.

  > It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature.

That's why you have a Project Manager / Business Analyst / Whatever Title You Prefer.

Few would consider going out and hiring their own construction crew to build their new house, managing materials deliveries, blockers, scheduling, head-count, etc. That's what a General Contractor is for.

But in software, both (some) business people and (some) developers think they can get away with attempting to go down a well-travelled path (by others) and do it all themselves.

Without that experience and expertise it's more likely than not IME that you'll spend more than you have to, and since you aren't a scheduling wizard and are trying to keep all this stuff in your head, you'll have numerous "stop work"s, conflicts, change-orders for half-baked designs, etc.

If you're building anything beyond the trivial, and you'd like to have a reasonable ball-park for what it's going to cost and how long it's going to take, make sure you're talking to the GC and not the plumber. And run far away from any business that tells you they cut out overhead by removing the GC.

I saw a slide not too long ago depicting a development process. It went something like: Skateboard -> Bicycle -> Scooter -> Car -> Truck.

If I'm the one writing the cheques, I'd be pretty pissed that I paid for four vehicles I didn't need before I got the one I did. Especially when it could have all been easily avoided by asking the right questions.

Agile can favor items on the left over items on the right. That doesn't mean you don't do the items on the right. It doesn't mean you start without a contract. It doesn't mean you don't plan. It doesn't mean you don't document requirements.

There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding. And when it inevitably goes south, best of luck getting the stockholder to fall on their sword for you.

Yeah, as a dev I would have to get some huge book of specs. It would make things very tedious. And, of course, take a huge amount of time to create and follow.

> "Writing good specs is important" - it's also really really hard.

Yes, this is a very good point. Unfortunately it's also a point that many non-software developers miss. Writing software is hard. Very hard. We, as an industry, should be pointing that out more.

> But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.

I'll submit that there's no way to know whether you are doing agile properly or improperly, unless you move to another company.

> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.

This smacks of elitism and it is what makes non-developer scoff at us. Developers are not gods, we're not even the smartest people.

We are simply the people that have to crystallize the requirements into a computer that only understands logic. Non-tech stakeholders can completely describe business requirements and also be made to understand the how their requirements fit into the logic of a computer. Non-technical people are not stupid, they just have different interests.

> You can't do that in a spec. It needs to be a conversation.

The spec is the output of the conversation.

> Have a conversation, understand what's needed, build good software.

And this is the most important thing said.

The trick with adhering to your statement is to define the parties involved in each step. Minimize those parties and then implement each step in order as fast as possible without sacrificing quality.

Remove the word "Agile" and the concept of software development, and what you've just described is how work has been completed for thousands of years. I fail to see how Agile comes into play.

> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.

Lots of developers are pretty bad at this, too; its more of a system analysis than coding skill.

> You can't do that in a spec. It needs to be a conversation.

You need a conversation directed by someone with a clear thought process that can encompass what is important in both the business and technical domains, ideally involving both business and technical experts, to get to a spec. But you absolutely can specify what needs to be done in a spec, and if you don't document the outcome of the conversation in one, its almost always going to be trouble down the road in any significant system. In the best case, its going to result in the technical staff answering lots of questions from business users (often, when neither the original technical nor business folks are in the same role) about what the system is expected to do, rather than actually working on system improvements.

If you replace specs with conversations rather than using conversations to get to specs, then everytime someone would otherwise consult a spec to answer a question later they end up consulting a programmer, instead.

Same here with vague requirements. Interesting enough, between requirements that are a couple of sentences that I pull out from a conversation or a 30 page requirements document, the vagueness is often a problem in both. In the former case, there just isn't enough information and it's clear that the feature just hasn't been thought out. In the latter case, the information is too detailed and there isn't enough room for interpretation of small, mainly insignificant (from a product perspective) details, on the developer's part. Either way, it ends up with a lot of wasted effort and a lot more time being spent on a project than necessary. Almost always, this is avoidable if the spec writers put in more effort in tackling the problem, understanding the system, and understanding what is and isn't possible.

All of the projects I've done over the last few years have been "agile" - the company I work for actually offers agile training.

Officially, all projects are written using TDD, and all estimates for all tasks should include time to write Acceptance and Unit following the suggestions in "Growing object oriented software guided by tests", along with any integration tests with external software that may be required.

Even unofficially, I've never seen anyone consider a story "complete" until there's sufficient automated tests for it, and there's been at least some manual testing.

Another thing we strongly encourage (and do) as part of Agile is regular retrospective meetings on our software development process. If our testing strategy (or lack thereof) was causing Fear during refactoring, prod bugs, or difficulty during maintenance, this would be bought up during such a meeting and addressed.

I'm not saying you're not "doing Agile", but your experience very strongly does not match mine.

Your experience is definitely unfortunate - stories/features being fully tested before being considered done, and therefore potentially shippable, is a key part of a successful Agile process. Without it, you are missing out on a lot of the possible benefits of the process, and I have seen first-hand the difference having QA engineers, even not particularly strong ones, integrated into the sprint can make to product quality.

A good first step to take would be to get your team together and work to define a Definition of Done, which should include both unit and integration/E2E testing (manual and/or automated) being complete - any stories not meeting these criteria cannot be considered as "done" and you can't count the points for them in the sprint.

Of course, initially this will probably cause lots of failed sprints and will decrease your velocity, but you have to see this as a positive, in that this raises visibility of the problems, and once you can identify the specific issues you're having and take the steps you need to resolve them (whether that's a lack of QA resource, or poor testing culture among developers, or whatever), you'll know when you say something is "done", it actually is done, rather than hiding a load of extra testing work that isn't complete.

On the requirements front, again defining a Definition of Ready can help - these are the criteria stories need to meet before you will estimate or start working on them. This should include things like requirements being clear, designs/UX being complete (if appropriate) and the story being testable and of a suitably small size for you to estimate with a reasonable degree of confidence.

Once you start pushing back on estimating stories because they don't meet these requirements and educating your product owners what they can do to improve the situation (for example, breaking stories down into smaller chunks, or defining requirements more clearly), you'll hopefully find the situation improves.

Of course, none of this is a substitute for conversations and working with the product team to help them understand what does and doesn't work for you, but I've personally helped make big differences to a team's quality and productivity by taking small steps such as these, in addition to educating the team and business on what "agile" is (without all the BS that some people will try and sell you!) and why this is important to us as developers and therefore to the wider organisation.

I used to work at a company that addressed testing with a three-pronged strategy:

1) when estimating, dev tests are part of the strategy (and, ideally, stories are written with enough detail to make testing strategies clear). Sometimes we review the ticket with QA to ensure that we both understand what's being asked for and what needs to be taken into account. Most tests at this point would include unit tests and functional tests.

2) Once a task is done, the story is reviewed with someone from QA to ensure it works. They suggest a couple of things to try that may require us to make improvements. The goal is to catch 80% of the issues at this point with 20% of the effort, and the pair-testing does a great job of flushing out issues. Here the focus is on functional tests and exploratory tests.

3) The QA team runs their own sprints testing the dev team's previous sprint's work. This is mostly performance and integration tests, but sometimes includes functional testing.

I thought the process was good because we were able to measure our software quality and address it quickly. That said, it feels somewhat cumbersome. This isn't an easy problem to tackle.

My boss in previous company forced analysts to write bug reports and feature requests in the form:

"how it works now, how it should work".

This took at most a month and made life for everybody a lot better.

I think yours is a different scenario?

The article suggests that developers trying to match business concerns with technical implementation disproportionately takes up time, as each feature was not spec-ed out and described properly in a technical manner.

Accumulating technical debt would be a delay purely on the engineering side. The engineering team is not always to blame, though.

remove the PM.

That might follow the pattern but it breaks a bunch of typical user story rules. It's easy to blame the format, but it sounds like the product owner needs to be educated on the process.

Joe Stump told a story on his podcast about this: the VP of Engineering would always tell the business side, “Everything always takes 60 days.” He had a high confidence that most tasks take 60 days.

Here's the link to the audio: https://soundcloud.com/business-of-coding/business-of-coding...

Waterfall is all up front. Agile is up front at the task level. Normally when commited to a sprint it doesn't change.

That might be more agile, but it's not Agile.

Exit earlier?

Feel more accomplished? Smarter? Have more unhassled free time to spend with their families? Get it over with so they don't have the "oh my god we're going to die" feeling hanging over them 24/7?

If "faster" equates to lower quality, bugs, more post-release thrash - simply to meet a contrived / marketing deadline - then none ;)

In my experience of building new things, rather than modifying existing ones, "Changes" would make less sense, as there is little or nothing to change.

Mike, you're one of my favourite commenters on HN. But this is one of your concepts that I've never been able to wrap my head around. Specifically:

>....business-driven software engineering. It does not work.

My interpretation "business-driven software engineering" (and please correct me if I'm wrong) is one where business determines the requirements of the software. But if business doesn't drive those requirements, who will? You've repeatedly shown how terrible the typical dev is at business, and most devs would seemingly cozy up to their IDE rather than navigate the mess that is determining requirements. So who's gonna do it? Besides, which dev doesn't hate a fuzzy spec?

Additionally, or perhaps more fundamentally, a business hires devs to the ends of furthering their, well, business objectives. What, exactly, is so wrong with business setting the agenda of what gets built?

I ask because of a lesson I learned early (and painfully) in my career as a sysadmin. Technology exists for the business - Not the other way around. Unless, of course, you're a tech firm, where tech itself is your business. And even then, a business has to make economic sense, and as a programmer, I think I'm allowed to say we typically make poor economic choices. McLeod 'Clueless', if you will.

There is a middle ground. Good managers will usually have a list of 2-3 things that you could be working on, and then the employee can pick one thing to work on amongst that list.