Ask HN: Why doesn't your team ship?
24 comments
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.
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.
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.
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.
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.
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.
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.
I think that while having heated discussions on redesign/changing a specification can be important, it is better to try and wrap up these discussions before you move into actually implementing your project. If you have too many debates while actually working on the architecture (IMO too many of these debates take place at this phase, rather than ahead of time), then the engineers work on implementing one feature only to be told they must abandon it and start implementing another feature, etc. Consistency can be a good tool for keeping projects running on time without growing costs, even if the overall design is not as optimal as it could be.
The problem with the debates is that it's difficult to discern when someone is debating with real authority on the subject versus appealing to authority.
A lot of engineers will say things "We need to use X, because Google, Facebook, etc use X". All the while ignoring the fact that Google and Facebook deal with massive scale, have tremendous resources to bear, and hardly get penalized by their customers when things break. The tech is only one small part of a much larger puzzle.
It's often easier to suppress such debates than engage in them, especially in the early days when you don't have the luxury of time. I'm not saying it's always the right thing to do, but it's often not the wrong thing to do for a team to continue shipping at a regular pace.
A lot of engineers will say things "We need to use X, because Google, Facebook, etc use X". All the while ignoring the fact that Google and Facebook deal with massive scale, have tremendous resources to bear, and hardly get penalized by their customers when things break. The tech is only one small part of a much larger puzzle.
It's often easier to suppress such debates than engage in them, especially in the early days when you don't have the luxury of time. I'm not saying it's always the right thing to do, but it's often not the wrong thing to do for a team to continue shipping at a regular pace.
3 - Seems like the kicker for new co-founders that start up thinking, "We share the dream so, we'll coordinate together."
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.
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.
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...
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.
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.
* 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.
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.
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.
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.
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.
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.
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.
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
Hotfixes ship as soon as they're done
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.
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.
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.
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.
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...
Fear. Fear indeed.
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?"
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?"
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...
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...
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.
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.
There's definitely a reoccurring theme here.
What do you think the best solution is?
What do you think the best solution is?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Can you explain a bit more? I've heard some team leads say their teams need more communication.
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.
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.
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.
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.
There are some good solutions to remote teams, as covered elsewhere. I work at Sococo; we have teams in 5 states and 2 continents, and we communicate well and continuously.
Sure. I haven't really concluded if this is a bad thing yet, but compared to previous places, this is what I have observed. And that is that we will bounce around an idea about something that is pretty (seemingly) trivial for longer than I am used to doing. Typically with the small things it has been "not really an issue, do this or that, it wont matter" where here we will communicate over a decision for much longer hashing things out. I think it comes from a good place of wanting to do what is right and make the best choice. And sometimes it feels slow. Now saying this is the wrong way to do things would not be an unbiased opinion since, all I have to compare it to is past employment experience. And my current place, regardless of the time accrued by these decisions, they are still quite successful. So really my observations are inconclusive at best.
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.
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.
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.
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.
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.
Only unchanging thing is the deadline.
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.
[deleted]
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.
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.
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.
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.
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.
The industry is obsessed with shipping the same way humans are obsessed with breathing
"frictions" is the best way to describe this.
some things better be left un-shipped.
What do you think the problem is? What's keeping your team from shipping? What slows down the development process?