
Ask HN: Why doesn't your team ship? - mijustin
Our industry is obsessed with shipping. And yet, I&#x27;ve been speaking to a lot of software teams lately, and it seems that everyone feels &quot;behind&quot;. They all want to be shipping better software, more frequently.<p>What do you think the problem is? What&#x27;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...](http://www.quora.com/Engineering-Management/Why-are-software-
development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-
Wolfe?srid=u8eL&share=1)

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.

~~~
nostrademons
They do improve the design of the architecture, but the question is "Will they
improve the design of the architecture more than shipping the product, letting
it contact reality, and learning from experience?" There's an opportunity cost
- debates cost time, time delays shipping, and shipping is what enables
customer feedback. In my experience, customer feedback and actual experience
is _much_ more important for improving the design of the architecture than
debating with other people. You can try to make your design slightly less
wrong by consulting with other team members who are equally as uninformed as
you, or you can get it right by going out and getting hard data.

~~~
kromodor
Unfortunately there is a psychological barrier that people must pass before
having the understanding of their lack of experience and the need to face
reality.

Only informing them about this, in some cases, is not enough.

It would really be well if people realized their bias, but they rarely do.

~~~
dk8996
Very well put. Most experienced teams just execute very well and individuals
can take on bigger roles while still seamlessly fitting into a bigger picture.
I think there is a bit of a gut feeling when you have experience -- more
likely your first step is in the right direction.

------
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...

------
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](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?

~~~
gatehouse
If it is someone who is in over their head trying to meet a goal or deadline,
then probably try to back them off before they burn out, and go back to the
planning stage and come up with something that has a chance for success. If it
is a noob-syndrome type then the best thing is to get them into an environment
where they can learn quickly what the ante is for a "real" solution -- so high
quality test data and mentorship are ideal.

------
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.

~~~
britman
I think the point being made is that ship cycles are very different between
B2C and B2B. I've experienced both (and to be clear I love the idea of
frequent small releases) but in a B2B scenario multiple daily releases are
simply not possible as you cannot use your customers as testers, I can assure
you if you try contracts will be terminated. We ship every two weeks and that
has taken a huge effort on our part to help our customers understand the value
of a frequent ship cycle. On the flip side I think you can do this in a b2c
environment (with appropriate quality controls of course) providing you
understand the revenue risks if something is shipped poorly (as you mention
with FB and Etsy), at that stage it's pure business priority trade off.

------
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.

~~~
jbob2000
In-office communication tends to be distracted by off-topic stuff like "Hey,
nice t-shirt!" or "How was the commute in this morning?".

Remote communication will have technical issues once in a while. If not that,
then it's the "telephone tag" game you end up playing. Also timezones.

I'm convinced that good communication is a symptom of other things being good.
Project has clear goals and everyone knows what they're doing? Communication
is good! Project is unclear, scope is too big, or just plain boring?
Communication is bad.

~~~
yojo
Communication quality also varies based on team cohesiveness. When I'm working
with people I like, I trust that they're being respectful of my time when they
communicate with me, and I am less likely to push back on a request that
delays my feature but is for the greater good. Employees are also better able
to negotiate around features/architectural decisions when they trust each
other.

I worked on a team with deep trust issues between the product manager and
engineers; PM didn't believe engineers were doing their best/giving fair
estimates, engineers didn't believe the PM was asking for features that would
lead us to success in the market. This lack of trust meant a big fight every
sprint, and a lot of productivity lost to arguments and the ensuing
distraction. Sample size of one, but the PM never had lunch with engineers or
otherwise engaged with them socially. I can't prove it, but I suspect things
would have gone a lot smoother if we'd all been friends.

tldr: Off-topic communication can still be good communication (in moderation)
because it helps develop/maintain high quality relationships between the
people you work with.

------
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.

------
paulgambill
Donuts and other crappy food. Typical office food treats like donuts, pizza,
and beer will all have negative chemical effects on team members. They will be
more sluggish, less creative, and less communicative in general.

~~~
drig
Huh. I started off laughing at this comment. But, I work for an organic
grocery company. Kitchen stocked with fruit, salad, healthy nut butters, etc.
We ship frequently. I wonder if there is something to this.

~~~
kromodor
Long term probably. I've read tents of studies on the topic and books on
similar topic. Junk food has long term effects, non of which are good. They
can affect various things, some of which, directly or indirectly, affect
higher order thinking, levels of energy, mood, activity and etc.

Also *x increased chance of various debilitating diseases.

Not to sound like a crazy health nut - there are two stupendous studies on the
citizens of Okinawa (The Okinawa project) and China (The China study) that
leave little doubt on the long term effects of junk foods.

So yes, it can.

------
chrismcb
The industry is obsessed with shipping the same way humans are obsessed with
breathing

------
gjvc
"frictions" is the best way to describe this.

------
trhway
some things better be left un-shipped.

