Hacker News new | comments | show | ask | jobs | submit | Ingon's comments login

One of the main things I've noticed is that every person is different and therefore every team is different. Also teams evolve over time, so even when compromised by the same people you can look at them differently "each" day.

I think the management should start with observing and listening. By paying attention to what's going on in the team you can start influencing it by praising beneficial (e.g. helping to meat the team goals) behaviors and preventing the un-beneficial ones. Then of course, when you have expectations from people, its best to get them on board as soon as possible and not leave them wonder why they've been praised and why "punished". Providing clear feedback as soon as possible seems to really work.

Another big thing you should watch out is what kind of people you've got on your team - intrinsically driven or externally driven. The more intrinsically driven people you have the less structure you need - its more about setting goals for them and getting out of their way. The externally driven people require far more structure and management in order to make them meet their goals.

In the end, because things could change quite frequently, I think the most important thing is communication - clearly and as often as possible, go over what we are trying to achieve and what could we do better to achieve that faster. For instance, although I'm hugely internally motivated, I'm really happy when I meet my "boss" and we get through all the things we are doing properly and what things we are not. Not having this kind of meeting for a long time is actually really upsetting.

Of course this scratches only the surface of what management is. Good luck on making an awesome team.


I wonder if somebody have tried using a STM style approach to making games?

For a couple of LudumDares I did try (in java) and for the games I was able to do it worked fairly well. Basically the drawing thread is seeing a frozen readonly version of the world (and keeps 60 fps) while the update thread will try to run simlation over readwrite version of the world. When the update thread finishes it will "publish" the new state and start over. I have ever wondered how it will perform at scale, maybe it will start braking apart if it grows too much?


It breaks down when you approach the hardware limits, i.e. for rts games with thousands of units on the screen, particle effects and so on, or if you have complex cad models in automotive applications. Essentially you then need to minimize driver overhead and avoid data copying at all costs. In particular you need to do memory mapped IO (using glMapBufferRange) between the GPU and main memory as fast as possible. That is only possible if you do tripple buffering with a ring buffer, at any given time one part of the buffer will be in flight to the GPU, one will be processed by it and the third will be modified by the CPU. You "publish" with synchronization (glFenceSync() and glClientWaitSync()), see for example http://gdcvault.com/play/1020791/.

In particular you have to organize all your world data in flat mutable arrays because even on the CPU your data has to be presented in a way that avoids cache misses as much as possible, this philosophy goes by "data-oriented design", see for example https://www.youtube.com/watch?v=rX0ItVEVjHc.


This is all very low-level stuff, though. Functional systems are high level abstractions typically erected on top of a low-level, imperative foundation. Let's use the particle effects example: One can describe how a particle system should behave using pure functions and immutable data whilst letting the actual simulation and rendering be handled by a low-level system that does all the dirty stuff necessary for speed.


I agree that it's potentially possible to make a functional layer on top, but it still seems somewhat irreconcilable with the idea of STM.


IANAGameEngineProgrammer, but I'd say it all depends on how you do the 'publishing' part. To do this in a performant way you need a language that supports pointers, so all you need to do in the thread safe part of your code is to swap two pointers (current and new). I'd assume the thread sync overhead once a frame becomes negligable (is there a good analysis for thread sync overheads on current x86?).


I came out as thinking helper. With the promise that I could enjoy becoming doctor. What a coincidence - I dream of becoming doctor :)


While performance is often cited as the main reason for having a native app, I think that one of the biggest reasons to prefer native apps is usability. More concretely I can see the following:

- A web app/site is often an app within an app. This means that what usually works as an interface to this device is no longer true, or rather different. The gestures are different, how the app is treating them is different and so on.

- On the performance side the web apps suffer from UI delivery problem - the site must deliver both the app it self and the data for which you use this app. A native app have to work with the data only, and its not restricted to be always connected with the web.

- Another reason is that although the same on the surface mobile is actually shifting our usage patterns. Our usage is far less consistent, more spaced out, under more conditions and with smaller screens. The native apps work well here because their components are thought out to work under these conditions and of course tested for this.

- Finally because of the usage patterns we see some native apps more versed to cover specific use cases. This differs from the mobile web which just have everything the normal web has, but tested to work on mobile.

Some of this points of course can be tackled by html5 wrapped web apps. But this approach comes with own set of limitations and problems - we are compromising on both openness and performance sides. So while I want the mobile web to work, for now I think that native apps are winning.


Your browser can cache a web app to be used offline. Plenty of Chrome apps are packaged this way. Firefox also has an option to do this, and Firefox OS can work without an internet connection. An HTML5 app is just source code obtained from a website that's run through a VM, and may or may not connect to a back-end (usually does though).

The problem isn't the web, it's how many web developers choose to use it. If you want to really know how powerful the web is, check out many of the WebGL demos and game demos out there...


I think if the curve is too steep probably you are trying to learn too much at a time. Focusing on small and well defined problems will help you out at least initially. For instance I used Project Euler[1] to study some of the basics, because the tasks there are well constrained and you cannot do too much architecturally. You will learn the mechanics of writing small functions, defining types, and then you can move onto something bigger, where high level concepts are involved.

[1] https://projecteuler.net/


I don't think ProjectEuler is very helpful for learning a language. The first ten problems or so might be useful to learn the basic syntax, but after that it's really just about number theory, or optimizing brute force.

If you're looking for Haskell beginner exercises, I recommend

a) implementing functions from Prelude, Data.List, Data.Tree yourself

b) doing the exercises given in RWH (even if you don't actually read the book - just do those you understand).

RWH: http://book.realworldhaskell.org/read/


exercism.io isn't bad either


> Because the types are known, there's an incredibly powerful testing framework called QuickCheck that is capable of e.g. generating tens of thousands of valid inputs and seeing if it can automatically disprove your assertions about your code. Python's typing is insufficient for this.

I think immutability also helps on this front.


Just being statically typed helps, there's nothing particularly special about Haskell that makes QuickCheck possible.


Have you read the source to Haskell's QuickCheck?

It can automatically derive automatic randomized generation of your data-types FOR you. No other generative testing library (such as for Clojure or Erlang) can do this.

Further, the random data generation can be customized using the functional combinator API.

Haskell QuickCheck's source code is a compelling example of what can be done with static types and typeclasses in Haskell.


> It can automatically derive automatic randomized generation of your data-types FOR you.

There's nothing about Haskell (or some extension to Haskell, I presume) that makes this possible that wouldn't make this possible in other languages like C#, Java, or, with a bit more verbosity, C++. If I'm wrong, please say what it is, I'd love to know.


You're wrong and you should look into how typeclasses, derivation, SYB, and GHC generics work.

That they aren't doing it is reason enough. Clojure and Erlang's QuickCheck libraries would derive Arbitrary if they could. :)


I already know how they work. Still waiting for an explanation of what they can do that you couldn't do in Java or C# or (with some verbosity) C++.

Edit: For example, to answer this question, you could define a type and explain how Haskell lets you automatically generate arbitrary instances of that type, where Java or C#, being as limited as you claim them to be, would be incapable of doing so. Edit: Also, Clojure and Erlang are irrelevant. My comment you originally replied to said that static typing was what makes QuickCheck possible.


Let's use circles and rectangels to motivate some analysis. In Haskell you might define:

  data Point = Point { x :: Float, y :: Float }
  data Shape =
    Circle { center :: Point, radius :: Float }
    | Rectangle { topLeft :: Point, bottomRight :: Point }
In C# you could similarly define

  class Point {
    public float _x, _y;
    public Point(float x, float y) {
      _x = x;
      _y = y;

  interface Shape {}
  class Circle {
    public Point _center;
    public float _radius;
    public Circle(Point center, float radius) {
      _center = center
      _radius = radius
  // etc, for Rectangle ...
Let's start from the C# end of things. Let's say we want to do some tests on random Shapes and that we want to get an instance of a random shape by calling Generate.random<Shape>(). There are a couple of different ways to do this. We could explicitly define a RandomShapeFactory and a RandomPointFactory and then wire those up into the Generate class. Maybe we could use reflection to dynamically generate instances of Points and Shapes from their definitions at runtime. It would probably end up looking like some combination of the two.

Haskell doesn't let you magically generate random instances of Shape. The cool thing it gives is the "deriving(Generic)" part. Effectively, this causes the compiler to generate a description of Point and the Shape-Circle-Rectangle set of types. In many ways, it's like C#'s reflection. The QuickCheck library uses this reflection-like definition to generate random instances.

The core functionality isn't very different, but Haskell's approach has a number of advantages. Most importantly, it's type-checked at compile-time. In the C# version, I could call Generate.random<Cat> and the code would blow up at run-time, whereas we would just get a compiler error in Haskell. The other major advantage in this case is the reduction of boiler-plate. There's no need to register factory instances inside of some singleton object at startup, the type system can infer which Generic components are needed where.

C# and Haskell are both turning complete, so you can do anything in either language. Haskell makes certain types of programming more enjoyable by reducing boiler-plate and preventing annoying runtime errors.

EDIT - code formatting


> There's no need to register factory instances inside of some singleton object at startup, the type system can infer which Generic components are needed where.

You would only need to do that if you wanted to define custom behavior, instead of automatically derived behavior, and registering a few delegates is the same amount of work as manually implementing an instance of Arbitrary and CoArbitrary.


Yep. The only really-real difference is compile time checking.


I'm interested in what you think of ScalaCheck[1]. It looks like at least someone is doing it.

[1] http://scalacheck.org/


Based on the documentation:


It cannot derive random generation behavior (Arbitrary typeclass in Haskell) for arbitrary data types. You have to write the generators yourself using the Generator class.

Which goes back to my point about generics, typeclass instance derivation, and the boilerplate using Haskell kills dead.


Hmm, I think you could do something similar to QuickCheck using C# generics. The biggest problem you'd run into is probably the same as Haskell does (the expression problem). You can get some ideas from http://www.daimi.au.dk/~madst/ecoop04/index.html.

Oh and you could probably always fall back to reflection and attributes, but that's just kind of cheating isn't it? ;)


>Hmm, I think you could do something similar to QuickCheck using C# generics

You can't do this. Quick check can generate type classes instances, for example, for tuples, functions, etc. This is impossible in language like C#.


There are certainly cases which aren't expressible(things which require kinding, for example) but your examples aren't a problem. Both tuples and functions can be represented using System F, and thus can be completely transposed into C# generics.

I believe you don't understand C# generics and you should look closer at the fundamental type calculus.


No it's not. The feature C# calls reflection lets you inspect types and generate them automatically.


If we use reflection, we might know about error only in runtime. What haskell does is guaranteed to work at compile time. That's why it's so cool.


QuickCheck doesn't do anything interesting at compile time.


"What haskell does is guaranteed at compile time to work."


Immutability is good but far from enough.


Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification.

I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed.

Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely.

Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)


What was it about your standups that were hurting your team?

I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.


Among the negatives of standups are:

- Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers.

- Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting.

- Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes).

- Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up.

- Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this.

That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.


I find it really hard to understand how a quick, 5 minute meeting every day can hurt a team.

> - Rarely the right information.

You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers.

> - Rarely at the right time.

We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline.

> - Failure to communicate.

You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there.

> - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him.

This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done.

A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting.

The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.


That all strikes me as being incredibly rigid for a process called "agile".


I'm really happy when I see bigger fonts promoted. I zoom in on most pages no matter if I'm on my big monitor on my phone.


Me too. For far too long there was a 'smaller looks nicer' attitude which completely ignored comfort and readability. Glad to see more thought going into typography.


I'm not, I'm always zooming out on those hipster sites. So I guess both paradigms are incorrect.


I guess the correct paradigm is to have a format that [ed: allows] simple semantic markup and simple aesthetic markup to combine with user preferences. Like html, css and user styles in browsers. We had it good there, for a few years around y2k.

People don't distribute letters and books for consumption in Eclipse and Visual Studio, I don't see why we should distribute blogs and web sites that way, just because a small percentage of sites are more like applications than just a collection of hypermedia.


Quite nice. You can think about touch interactions (maybe you have, but it was not working on iPhone)


I wonder how much pollution is generated to make the bike. This is a genuine question, I don't mean to quarrel. I'm certain that car is polluting far more then bike of course.

There is certainly some from the paint and the tires (mostly oil right?). I wonder what else?

EDIT: The initial text was stating that a bike pollutes more then a car which is obvious shit. This is just my english at its finest. I'm sorry for this.


I'm not entirely sure what your point is here? The pollution generated by making a bike will be orders of magnitude less than the pollution generated by making a car.

Following on from that, the pollution generated from day to day upkeep will be less as well (when was the last time you had to change the oil on your bicycle?)

Lastly, the energy required to power the bike (the energy that you provide), is a bit of a sunk cost, you need to eat to stay alive after all, and while you _might_ need a little more, it's still not going to be equivalent to driving your car to work and back every day.


Orders of magnitude? Doubt it. Check out http://bicycleuniverse.info/transpo/energy.html - while biking is typically more efficient than driving, it's not orders of magnitude. If you play with their calculator, you can find that driving a 50 mpg car and riding a bike really fast both have about the same carbon emissions. This is just from factoring in increased food consumption.


Thanks for sharing that link. It's interesting to think about this. I don't agree with the conclusions, though.

First of all, your metabolism isn't going to stop (assuming you're still alive), so it's not really fair to say that those calories you burned wouldn't have been burned if you hadn't biked. I exercise a few times every week. If I bike less, I just have to do more exercise, but i burn about the same number of calories.

Secondly, most bike trips are short and relatively low speed. Biking encourages you to explore your local area. Lower speeds mean lower wind resistances, and shorter trips obviously make the mileage considerations a lot less important. I really don't think I'd be willing to travel more than a few miles by mike, since I don't want to spend hours in transit.


Your link doesn't mention the resources used in the production of either a bike or a car.


A bicycle will have a smaller carbon footprint when it's made (reduction of material etc) than a car, and lower carbon emission costs as it's used. A car in theory if it's well taken car of can be used for decades, as can a bike. A car will need regular oil changes, new fluids (brakes, etc), new components as parts fail, more equipment is required to work on it. A bike will require cleaning, oiling and maintaining, new tyres as and when needed (probably about the same time scale as a car), but has less components than a car and generally requires fewer tools.

Overall whilst a bike isn't carbon neutral to make, it'll produce less over it's life time.


What do you mean by "I'm certain that it is far more then what car needs"?

Let's guess that a car weighs about 3000 lbs, and then let's guess that a bike weighs about 20 (obviously there is large variance). Mining or producing all those resources produces pollution, we can even generalize it to be similar levels of pollution. The 3000 lbs. of raw materials times the pollutant level will, by far, be the dominating factor in the 'how much pollution did creating this thing create' equation.


Making a bike pollutes more than making a car? Not even to mention usage pollution itself (which I primarily had in mind)... Also, just compare a lifespan of a car vs. a lifespan of a bicycle. I have several bicycles, the one I use mostly is around 20 years old, I have others considerably older than that, still functioning perfectly.


Yeah, there's no way making a bike pollutes more than making a car.

However, there's a slightly more interesting analysis to be had if you consider that car fuel is way more efficient than bike fuel (human calories). So maybe, just maybe, a sufficiently poor diet can cause riding a bike to work to be worse for the environment than driving.


Sorry, it's very hard to even conceive the constraints and abstractions under which a bike would be worse for the environment than driving. First and foremost, riding a bike relies on sustainable energy (grow, eat, repeat). Cars are still far far away from being remotely sustainable.

Car vs. bike discussion may have (some) sense when it comes to commuting distances, adverse weather conditions etc.


All purchased food relies on unsustainable energy sources and nearly all food relies on unsustainable fertilization and other petroleum derived products.

I have a super minimalistic garden and grow some of my own salad vegetables in the summer but I'm under no illusions and 99% of my food calories come indirectly from crude oil and natgas.

My car doesn't burn biodiesel and isn't made of soy. The store is illuminated and HVAC by natgas and coal. The delivery truck from the warehouse doesn't burn biodiesel and isn't made of soy. The warehouse burns lots of coal for its HVAC and lights. The trucks delivering to the warehouse don't run on biodiesel and aren't made of soy. Assuming produce and not "processed food-like substances" the farm uses diesel to run the tractor and other gear, some coal powered electricity in the greenhouse, fertilizers made of phosphates dug out of the ground (what to do when they run out?) and nitrates made by the haber process outta lots of natgas. Also there may or may not be herbicides / pesticides / fertilizers made out of crude oil.

If your food is cheaper per "gallon" than diesel, its at least theoretically possible to make it with biodiesel and be net energy positive. If it takes 20 gallons of diesel equivalent environmental damage to make a gallon of walnut oil, then if you poured walnut oil into a biodiesel tank the system would rapidly run dry and halt.

Computer science types have a stereotype where the "halting problem" can't be solved for them so it can't be solved anywhere, although energy calculations are actually pretty simple (yes yes I know totally different type of halting its a bad joke). If (Energy Returned) is less than (Energy Invested) then the only way to keep pumping food out is to burn crude oil to make up the difference.

Depending what axe you have to grind, EROEI of food varies from 0.1 to 1. The truth is probably within that range, perhaps 0.3. A pound of fat (animal hydrocarbon, basically) is worth 3500 or so calories so the environment is better off if you burn two pounds of gasoline than if you eat a pound of food (aka equivalent of 3 pounds of diesel burned to make it) and bike the same distance.


2 pounds of gasoline is about 1/3 of a gallon. So a charitable 20 miles of car range.

3 hours on a bike at a somewhat moderate pace isn't going to be more than 2000 kcal. Of course, animal fat is like 10 times less efficient than directly eating the vegetable calories.

I guess an electric car that recycles well might end up beating the bicycle though.


Are you seriously suggesting that I polluted more by cycling to work (for the extra food that I had to ingest) than I would if I drove instead? Can you point me to some reading material which would prove that? Thanks.


I don't have enough datapoints but its quite possible.

One big problem is the EROEI of food varies so much. Kobe beef flown in by air from Japan as a bicyclist fuel is likely to be vastly worse than driving a typical car, yet eating home grown vegetables is likely to be better than driving a V8 crew cab pickup truck. No debate there. Are you better off eating a little more factory farmed chicken on factory farmed rice fried in chemical plant produced psuedo-oil, or burning gasoline, well there's a debatable area.

You'd do best to google for EROEI and related terms. Warning that all reports in the field are highly politicized, so you need to average the archived stuff on theoildrum showing a 0.1 with some multinational megacorp astroturfed greenwashing campaign claiming a 10.0 EROEI.

There are no unbiased academic textbooks I'm aware of. Its all "The Peak Oil Myth Debunked" or the "Partys over" book and "Crude awakening" movie and there is nothing in between.

Generally the pessimistic treatments do a good job of science and engineering and math and do a bad job of politics, economics, PR and emotional response. And the optimistic treatments do the obvious swapped topics. So if you critically read both and pay attention appropriately, you'll come out with the best of both (try not to mess up and end up with the worst of both sides LOL)

For just one book, you could do worse than read Kunstler's emergency book. Not because its perfect or even because I agree with all of it, but because it is extremely content dense WRT listing the many inter-related systemic problems. It makes at least passing mention of almost all issues, and at least one sides thoughts about it, regardless if you agree or not. I don't think the "other" side has anything near as information dense, that I know of.


Although there are outliers with super-bikers riding 20 year old bikes for thousands of miles per year, joe 6 pack average dude finds bikes are extremely high maintenance demands per mile, expensive to maintain per mile, and make 1970s detroit iron look reliable and long lived.

I have a "Giant" from 1992 and I am not a serious bike rider but I believe I've purchased more tires for the bike than for my car, despite commuting probably 100x further in my car. Bikes are a serious headache to maintain compared to a decent car.

If someone could design a bicycle that lasted as long as a car for normal users, that required as little maintenance as a car for the first decade or so, that was as reliable as a car, that blew out tires as rarely as a car, then it would be one heck of a bike... unfortunately due to lack of economy of scale and having almost nothing in common with conventional bike design, it would probably cost almost as much as a car...


Such bikes do exist. Unfortunately people's expectations of cost are skewed by cheap bicycle-shaped objects in department stores.

Look at nations that have cycling as a way of life. "Mama fiets" (apologies for potential misuse of Dutch language) are robust bikes for carrying children and shopping around.

There are puncture resisting tapes that can be applied to tyres.

Most people don't need fixed wheels, nor 20 gear derailurs, but would do well with 5 well chosen gears.

Aluminum frames (with modern welding and tube shapes) are light and robust. And probably a good use of recycled aluminum.

And people tend not to educate themselves about cycling. Having the seat post at the right hight makes a huge difference. Using the balls of the toe on the pedal and not the arch of the foot makes a huge difference.

Many people would be served well by a £500 bike and a book about cycling. Include a basket and some panniers and mud guards, with a can of spray lubrication and a few spare tyres and replacement chains.

I agree that cycle shops usually are not set up for this, and that the image of flourescent lycra is off-putting to many people; and that it would be great if commuting by bike was more accessible.


Ex bike repair professional here.

It's definitely possible for your bike to need way less maintenance than a car and to provide very few headaches.

In your case, I recommend that you buy very good tires. Most bikes have cheap tires, which dry rot. Some of my bikes have tires that are 6-10 years old and still working fine. They also cost $40 apiece back then.

In general, most bikes are designed for the recreational "joe 6 pack" market and are of poor quality. If you expect a bike to work well and last a long time, you have to pay extra.


It really depends on what kind of bike you buy. I have a steel-frame bike with hub gearing. It's never needed any repairs for 3 years, aside from tightening a bolt. It was really surprising to me that when I switched from using a derailleur to using hub gearing, I suddenly no longer needed to get my bike tuned every 2 months to avoid gears slipping. And when I got a steel frame, I suddenly no longer needed to worry about it bending out of shape all the time.


You think making a bike is /more/ polluting than making a car?


You are certain a bike generates more pollution over it's lifetime then a car? Or only in the manufacturing?


A worthy third option is "per mile".

I got 160K in 16 years out of my last car. It cost about $20K. I figured its total lifetime cost including gas and what little maintenance it needed at thirty five grand. So figure about 20 cents per mile. That's cheaper than average, then again it was more of a beater of an old car that most would tolerate. Mechanically fine, but cosmetically a mess. So yes twenty cents per mile is not totally ridiculous.

Being a purely recreational biker I suspect I've only got 1K or so miles on my "Giant" bike from 1992. It was about $300 but the way tires decay (why so much faster than car?) and general minor repairs I'm sure I'm in for $500 by now. So I'm paying 50 cents per mile, or about 2.5 times more than my commuter car costs the environment.

Worst of all, being a recreational bike, I've caused $500 worth of environmental destruction just for fun when I could have meditated or bird watched or gone hiking. And if you get rid of the recreational bikers, that's a large market segment so costs and enviro-damage will increase. Aside from the obvious win of get rid of recreational bikers, well, they'll just drive to the mall with their new spare time or whatever.

I'm sure I could game the numbers and if I had a recreational car and a commuter bike the numbers could be made to look different. One problem with a commuter bike is the weather only cooperates about 1/3 of the year, and my car goes easily six times faster than my bike, making the commute punishingly impossible.


my guess would be that bikes contribute to the pollution by slowing/congesting the traffic (even with a bike lane it means taking driving space away from cars - adversely impacting the flow of cars).



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact