Ask HN: Why doesn't your team ship?

[mijustin]

Our industry is obsessed with shipping. And yet, I've been speaking to a lot of software teams lately, and it seems that everyone feels "behind". They all want to be shipping better software, more frequently.

What do you think the problem is? What's keeping your team from shipping? What slows down the development process?

[chollida1]

Here is a very popular Quora question that details alot of the reasons why software estimates are wrong:

http://www.quora.com/Engineering-Management/Why-are-software...

When I look back on my career the patterns that lead to good development were:

1) small team sizes, I'm a big believer that if version 1 of your product is developed by more than 4 people, its in trouble:) Small, super focused, and highly talented teams make the best version 1 products in my opinion, probably related to why some start ups can be more agile.

2) Everyone on the team has domain experience, ie its not the first time a product has been written. This is slightly at odds with the "second system syndrome". At my current company, when we wrote our algo platform, each member had done this before so we knew from a data, networking, machine learning, and trader's perspective what we wanted to get done. There was very little flailing around trying to learn the domain( ie no learning what ml techniques to use, how to connect to exchanges via FIX, no learning what a pairs trade was, etc).

3) 1, and only 1 person in charge of the vision. This might be obvious but debates, even when they are well intended, seem to slow things down. Having one person dictate what the next version will have seems to make things much easier. This is especially obvious in my current field of finance. Its very easy to spot the products developed by engineers for traders, vs the products developed by traders for traders, The former have lots of features that no one wants but they look pretty and the later, look ugly but make money:)

META NOTE TO ANYONE DEVELOPING A TRADING SYSTEM No one cares what it looks like. I'll say that again, no one cares what it looks like. The Bloomberg terminal is the ugliest thing on the planet and they mint money. Function over fashion, always. I'd go as far as to state that a small team developing a trading system having a designer is viewed in the same light as a small team having an mba. That person might add value, but you'll need to justify why you're there instead of another engineer.

I think alot of not shipping can be tied to these three things, too large of a team, not knowing what the final product will be doing and hence alot of experimentation and wrong turns and competing visions, or a lack of vision of what you are building.

[tieTYT]

I ask this without having my own opinion on the matter: Won't those debates improve the design of the architecture? It's hard to imagine the time loss of debates being greater than the time loss of a rearchitecture.

[jonalmeida]

3 - Seems like the kicker for new co-founders that start up thinking, "We share the dream so, we'll coordinate together."

[cognivore]

Changing requirements.

Us: "Well, we just got the roof on and all the walls sheetrocked!"

Them: "We want all the walls moved now."

Lately it's also been the strangely recurring request to do the impossible. I've actually been asked to use cross site scripting ("like the hackers do - why can't you do it") to implement features a customer just had to have.

[msoad]

Culture of bullshit. In some companies, the better you produce bullshit and fluff the better you get treated. Nobody cares who is doing the actual work. Whoever speaks about that work will get rewarded. In such culture, people who can do stuff will escape and people who assemble bullshit all day will stay. Then people wonder why nothing is being shipped...

[dhimes]

This is really tragic when it is whoever speaks poorly about that work will get rewarded. It's easy to throw stones and sound smart; it's very difficult to create. And so many managers (and others, actually) can't seem to tell the difference.

[justinweiss]

Two main things:

* Bad estimates. When people are too aggressive with their estimates and miss them, it derails everyone that was depending on that team's stuff being done at a particular time. It causes blockages that cost way more than an over-estimate would have reserved as buffer time.

* Getting distracted. Dev should work really closely with design and PDM to get things done, but if Design / PDM has already moved on to the next project, it's distracting for everyone when they have to get pulled back in. Then, you have multitasking, and blockages, and stuff doesn't get done as smoothly as it should.

[cik]

I realize that I'm going to sound like a grandfather here, but I think it comes down to a lack of history. Teams with that young/old balance, people who have done it before ship more frequently, from what I see.

Years ago, that was called Build Management, now, we call part of it DevOps. But the reality is that most teams have forgotten about professional engineering.

Pausing to think about the 'how' rather than just hammering it out, and living with the consequences are enormous. The fact that I rarely see separations of concern anymore, let alone focusing on reducing build times or test run times, is massive. Ultimately, that means tradeoffs - the software triangle comes into play.

It's especially interesting to me, since I'm (today) working with a team I last worked with 12 years ago. There's been massive flux - only three of twenty originals are here. And yet, with multiple geographies, multiple age groups, multiple operating systems, and three distinct cloud providers (let alone the internal wannabe cloud) they push out a valuable release weekly, and micro-push to production ~3x daily. That's a testament to the engineer who manages the team, the same engineer I worked with on build workflows over a decade ago.

[lifeisstillgood]

I call this the "steadfast captain paradox". Your engineer is like the captain of a ship who detours around storm and arrives in harbour two days late uneventfully.

Unlike the captain who lost a mast passing through the storm and limps to harbour a hero who saved the ship, our engineer goes unsung.

I hope your Collegue has been able to capture for himself the money his employers did not spend on crash rebuilds, massive emergency development programs and lost productivity of the main Dev teams ....

No?

Like our captain friend ... Only work for admirals who have sufficient ships that outliers stand out.

[davybrion]

Corporate release cycles... In large corporations, you rarely get access to the production environment and everything is managed by different departments. At my current client, we can only go to production a few times a year (except for hotfixes, but they need to be approved by a special board).

Luckily, our deployments are automated and we deploy to our testing environment multiple times a week, sometimes multiple times per day. That at least enables us to get feedback from the test team, which results in tickets either being moved to 'really done' or moving them back to 'in progress'. It's not the same as shipping, but in such an environment it at least reminds you of the important fact that things are indeed still moving and getting done.

[arenaninja]

Similar boat. Not corporate, but our paying clients are school districts. Plenty of teachers are technophobes, and evolving UIs and new features are a burden (in fact, we have a 3 month window each year where truly new features are rolled out), and users need to be retrained

Hotfixes ship as soon as they're done

[MalcolmDiggs]

In my experience it usually boils down to delusions of grandeur. Stakeholders often think THE WORLD is watching this upcoming release, so they can't possibly allow the team to ship without features X Y and Z ready.

In reality, for the vast majority of launches very people are watching, and even fewer care about your features or lack thereof (that's just not how early-adopters think about products, in my opinion).

If founders realized how little traffic / how few downloads they were going to get out of the gate, they'd ship much earlier; unfortunately everybody thinks their project is going to be a TechCrunch headline, and that's just not the case.

[jasonlotito]

Looking beyond what other people have mentioned, these are things that plague teams:

1. Fear of failure. Too many people are afraid to ship too soon. They fear a bad product out the gate, rather than getting out the gate in the first place.

2. Lack of focus. You'll spend too much time focusing on things that don't really matter, such as building the perfect messaging system rather than reusing something that exists and works now.

3. Busywork. You'll spend your time doing things that really don't matter, such as optimizing your icons to use fonts instead of a PNG, and then dealing with trying to make it work in older versions of IE.

[jaderobbins1]

1. Fear - this is a problem at ALL levels of organizations. Designers don't want something out that they think doesn't look jaw dropping, product managers don't define a clear MVP and feature creep keeps piling up, management doesn't want something released unless it feels groundbreaking...

[stefan_kendall3]

Fear. Fear indeed.

[jbob2000]

Not enough planning and general apathy.

We'll start a project and then half the devs will go on vacation. They return, and then the other half go on vacation. I guess that's summer for ya, but why not just close the office for a month and let everyone know that they should take their vacations around that time.

Devs will raise complaints about the work environment or a poorly written (but critical) module, but nothing gets done about it.

If a feature doesn't have strong executive support, nothing really gets done on it, and 3 months later someone will ask "hey, what happened to that feature?"

[GFischer]

That sounds like a management / leadership failure (ok, I'm being Captain Obvious here).

I've been one of the "apathetic" people before, I've seen it happen due to burnout, too many times working with no recognition, lack of faith in the higher ups, etc...

[gatehouse]

Essentially the exact same issues everyone else faces, which are covered exhaustively here: http://www.stevemcconnell.com/rd.htm

I'm going to single one out though: tweaking: making changes without adequate anticipation of the effects, or without the theoretical backing to expect that it will be correct. When you have a well structured high level understanding you can make changes knowing approximately what the effect will be and converge on the solution. Without that you end up thrashing around and making changes at random. If you take a random walk you're probably not going anywhere fast.

When you are dealing with a well designed and executed system, then tweaking actually seems productive, because you begin from a good place in the solution space, when you explore the "local neighbourhood", then the modifications still produce a functional piece of software and it might actually be better in some ways that you care about.

When you are making something new, tweaking gets you nowhere.

EDIT: Here is a foolproof process to get me to automatically disregard all your future ideas:

1. Find some parameters that were chosen with theoretical justifications and a real analysis of historical data.

2. Modify one of the parameters based on some flimsy rationale.

3. Run some quick tests that are obviously designed specifically to confirm your expectations, declare victory and act like you've solved something.

[mijustin]

There's definitely a reoccurring theme here.

What do you think the best solution is?

[canterburry]

Well, some of this is also over exaggerated. I have spoken with some of the people who work at these "ship multiple times a day" companies and they only do this for their less critical systems. Their core money making stuff is less frequently updated.

It also depends on what domain your company is in. If downtime doesn't lead to anyone's death, doesn't send you to prison or millions in lawsuits from Enterprise customers...sure ship daily.

[tatalegma]

Are you implying that shipping multiple times a day means downtime? What about Etsy, where downtime means lost revenue? Facebook? I'm sure if they go down, and therefore people can't view or click ads, they miss out on revenue too.

[pan69]

The No. 1 problem for me always seems to be:

Not having a clear and concise plan. For software development this means obviously a detailed and worked out feature set.

It amazes me how often a development team is set out on the journey of building a system without clarity of what it is it's trying to accomplish. Sure, the high level functionality is there but as developers you need to know low level stuff. Usually this due the lack of leadership. A word to the "CEO's" out there;

A vision that's not formalised in a document and shared with the rest of the team is not a vision, it's fantasy.

Sure, I get it. For you, the CEO, it's easier to make stuff up as you go along than it is to write stuff down and to commit to it.

As a developer, when you try to get functionality formalized then those meetings to discuss the functionality turn into "design" meetings where everyone has to come up with new "awesome" ideas which means that at some point the team stops having meetings to discuss things.

It doesn't matter how much experience I have as a developer, I simply can't cram the full time role of project/product manager and at least 40 hours of writing quality software into a single week. Something has to give.

[yellow_and_gray]

It's not possible to have a clear and concise plan.

You first need to figure out what the problem is, and you won't figure that out by writing a detailed and worked out feature set solving a slightly different problem.

[winslow]

Red tape and general overhead of a massive corporation. We can't get anything done. They move way to slow for us (team was aquired ~3 years ago). We haven't delivered anything remotely useful for two years. I'm currently looking to switch companies. Oh also the mandatory 45 minute training we had on how to use a new internal HR website that was a complete waste of time.

[misterparker]

As a remote team, communication may be what slows our team down. But on the same token, in-office communication can slow things down too.

[mijustin]

Can you explain a bit more? I've heard some team leads say their teams need more communication.

[Htsthbjig]

Bad estimates: You don't know what you don't know. You don't know how much time it will take to do something you never have done.

Problems are dam hard: What we do is really hard, so basically we have to trim our projects to the basics, instead of doing what we want to do, which is way more. Creative people want to start-create always way more projects that what they could finish, so we need discipline here.

*Complexity and lack of documentation. Another thing that needs a lot of discipline. People believe that what they know after thinking on it for a lot of time is evident for everybody else. It is not. Not only that, people forget what they know today if they do not document it, so if you do not document a year from now you will repeating most of your work, with the company's budget.

[aytekin]

Scope: The larger the project, the harder it gets to release.

Tools: The longer it takes to release, the less it will be done.

Culture: The harsher the response to failure, the less risk shall be taken.

[scotty79]

Requirements mostly undefined, delivered one semi-random brushstroke at a time. Part of requirements communicated so far changed as we go. Two rewrites of the front-end, including one with whole front-end stack changed from desktop client to webapp. Both rewrites used to change requirements for the front-end and back-end parts.

Only unchanging thing is the deadline.

[vishalchandra]

Not having a detailed and thorough product definition delays the end result. The development is fast but if you keep recoding the same functionality with different color, different fonts, different form fields you are constantly shifting the goal posts. The solution is to ship the ugly (unfinished version), get feedback and then ship again.

[JoeAltmaier]

Once we got to a stable functional release, the bar got raised for releasing a subsequent client. Change means instability; instability means it won't be shipped. So changes accumulate, the code never sits still long enough to shake out all the instabilities.