Whenever I read articles that explore technical innovations for the developing world, I have two simultaneous reactions.
The engineer in me is impressed by the creativity, the design process, the constraints that bring forward ideas like this. I remember doing a very similar design project in my first year of university where we were asked to design a shelter that could house a family of 4 for up to 3 months following some sort of natural disaster. We could pick the location and the disaster, but it had to all fit within a shipping container and had to conform to basic codes. Such constraints did indeed drive innovation and the resulting designs were as varied as a bowl of marbles. That is to say that they were all different shapes, sizes and colours, but they all served the purpose of a house.
So when I see the engineering discipline highlighted and starting to engage with some of the world’s toughest problems – like housing for the poor, water and sanitation, solar lanterns, etc – I’m always interested.
Then the second side kicks in – that social scientist and development worker in me – and the scepticism starts to erode the previous excitement. Development workers as a group are notoriously critical of others ideas, especially if those ideas purport to have THE solution to solving problems.
The social scientist in me has seen too many failed “silver bullet” solutions that were designed in America to help people a world away. I’ve seen too many technical fixes to problems that are not technical in nature – or at least not technical in a building stuff way. I’ve seen too many decent ideas that have been poorly implemented and have resulted in bigger disappointment for the beneficiaries than when they stated. I’m sure that along the way I have also made all of these mistakes, but I like to think that I’m learning. So if I’m cynical, it comes from experience.
Back to $300 houses and technology design and distribution though. As some of the comments have already pointed out, there are a few important assumptions that would need to be addressed before this could work. Important issues like land ownersip and the reasons why these slums exist in the first place.
There is the added dimension that is not being talked about which is that people do not aspire to being poor – they want to get wealthy (or at least financially secure) to enable them to access the opportunities and lives they see around them. Designing and marketing a technical solution for “the poor” has been done before – its called a latrine. When NGOs went out to build or have communities build latrines, they found that people were grateful and accepted the new system, but often didn’t use it. It became a decorational symbol of a failed implementation on a low-cost, low-energy solution. People didn’t want latrines, they wanted toilets because that what the people that they aspired to become were using.
As a friend quite accurately stated “The problem is not the hardware, it’s the software.” It’s all the systems that go into maintaining, improving, adapting technology in the context. Maintenance schedules are often disregarded, as are the mechanics and spare parts required to repair a borehole. These are traded for more boreholes in an attempt to go to scale – drill more faster. In water as in agriculture or housing, the technology is only part of the solution – what determines success or failure is how people use and interact with it. We know this in our own context, but so casually ignore it in others. This drive to scale means that development agencies often forget to reflect, to learn, to admit failure, to start small and disseminate solutions that work over time. The problems are immediate, but immediate band-aid solutions will not fix them.
While I applaud the engineers in this experiment for getting involved and trying to use their skills to tackle a tough and growing problem, I’d advice caution and more thought on how this design would be marketed and used (and by whom) before calling it a success.
Now that the initial design phase is done(presumably from America), I would recommend a small test phase – a prototype in design language. This step, done genuinely, is almost always missing from development projects. To prototype genuinely is to admit that you may not have it right on the first try and that it might require you to go back to the drawing board with tough feedback and ideas.
Some unsolicited ideas might be:
- Enrol Indian engineers that have worked in the communities you are targeting to help you.
- Set up a design competition in universities that would get Indian engineers working on these types of problems, and mandate that they think about implementation and maintenance. Not only would this bring in new ideas, but it might also get a group of Indian students working and thinking about these problems. You could hire the best of them to help you make this work.
- Consult local NGOs working in the area to provide the social context.
- Get feedback from the community and community leaders.
- Expect failure, but also expect great learning from which a better and more appropriate design can emerge.
So where does that leave me – the engineer and development worker? Excited, sceptical and listening.
Other People’s Perspective