What ideas from other professions have you applied to software development?

Question

The software development community is always open to new ideas to improve the way we develop software, and it seems to me that we innovate more than other engineering disciplines or professions.

However, it seems that it would be unfortunate if our relatively young industry failed to learn from established professions. There must be some great ideas discovered by people outside of software developmentthat we could benefit from.

Can you describe any ideas, techniques or processes used by other professions, that you have applied successfully (or not) to your software development?

Answer 1

Eliyahu Goldratt has a book called "The Goal" which is a novelized business book on optimizing a factory. It has a lot of good discussion on how to determine reality (or at least question your own concept of it) plus stuff on bottlenecks which is very useful when an overall scalability issue.

Answer 2

Psychology is the one. Its not just motivating yourself and your teammates, but using techniques to understand what the customer actually wants instead of what he asked for. Usability is something else that matters to software development that is a person-oriented factor.

Software may be a technical profession, but developing applications is a human one.

Answer 3

Any sort of Construction activities - I always have amazed on the vast constructions(Bridges and Buildings) than on great softwares. Because you have always have more oportunity in s/w to test(unit,stress,User acceptance and hell lot of quality checks), but imagine how much you can do about a great structure Good background in Physics and Maths will surely boost your programming skills

Answer 4

Lean development is an obvious choice, taken from Toyota's manufacturing principals to combat economies of scale of the might U.S. industry. It fits well with the agile software engineering framework

Answer 5

This may be a stretch, but while playing Table Tennis I learned that after you gain some basic skill, most of your mistakes come from trying to play better than you actually are - going for slams you really don't have the skill to make. It's safer to play a conservative game and let the other player overplay themselves.

While coding, I try not to be cleverer than I am. (Running architecture designs by people helps with that). Implementing complicated data structures to manage dirty reads and cache expiration got shot down quicky, as the feature was for a subset of users, and wasn't worth the memory or developer resources.

I believe Fred Brooks would call this the Second System Syndrome.

Answer 6

Personally I find that a background in math and science comes in very handy when troubleshooting and debugging. Using the scientific method, enforcing intellectual rigor on yourself, maintaining healthy skepticism, and always stepping back to the question "does this theory actually explain the observed evidence best?" helps enormously in tracking down root causes instead of being side tracked by false leads.

Answer 7

In, sort of a vague sense, construction taught me to think in terms of efficiency. When you're on a jobsite packing your work bags around, hauling lumber, dragging power cords through cluttered, unfinished rooms and hallways and generally breaking your back turning a huge pile of lumber and plywood into a house, you learn quickly that every move you make has to do something useful. This is especially true when you have a small business owner boss behind you, yelling about how he loses money every time you walk from point a to point b without taking something with you.

In programming, it can often be the same. Instead of saving your back, though, you're trying to save time. This takes the form of easily maintainable and re-usable code. Every time you make a new function to do something painfully similar to another function, or you make a new class that could easily be inherited from something more generic, but almost the same, you're robbing yourself of time and money, just as much as if a framer takes 6 trips back and forth to do something he, or (rarely) she, could have done in one trip. In both cases the payoff is less time working on a big stupid job, and and a happier richer boss.

Answer 8

I spent 14 years doing industrial engineering type efficiency studies. That taught me how to interview people for information especially when they aren't cooperative and how to get information from sources other than interviews (very useful when gathering requirements) and how to think analytically and most especially how to really understand data from both a business perspective and a user perspective. This is especially useful in designing databases. When you've had to extract data from as many poorly designed databases as I had to use when I was ana anlayst, you learn what works and what doesn't. Unlike the average programmer, I've used the data from literally thousands of different databases.

Answer 9

Design patterns were originally used by architects (i.e. people who design actual buildings, not software architects).

Answer 10

The old carpentry saying "measure twice, cut once" has always been applicable to development projects I have worked on. It pays dividends to strive to get things right the first time around.

Answer 11

There are too many to count and they relate in such various ways that make the question a little bit rhetorical because programming in essence is a mixture of logic and math designed to interact with any other field to provide solutions / automate tasks for real life situations. But to provide this you would have to implement a good part of that domain logic in order to make something useful.

So software development it's not the purpose, it's possibly a solution, or the solution to every problem implies notions from the domain itself.

I don't know if my answer covers the question because it's a little too general as i see it.

Answer 12

I nearly ended up teaching ICT in secondary schools. I learnt a lot:

• Even teachers are still students -- still learning all the time.
• The best teachers are also the best learners
• You can learn a great deal from those around you, no matter what their skill levels
• Preparation is often the key to success
• Assumption is the mother of all f**k-ups
• Technology changes too fast to keep up with all the latest developments -- admit you don't know everything.

Answer 13

As a consultant I've learned to smile and give the user whatever they ask for...

I can't mention in good company what profession I've modeled this behavior after.

Answer 14

KISS (Keep It Simple, Stupid) principle applies here just like it did in my Mechanical Engineering studies. As far as coding is concerned, it is most likely that more time will be spent by the developer and others reading the code than writing it. Therefore, it helps a lot to have as simple a design as possible for the given problem. Over-engineering in this field will have even the original developer scratching his/her head three-six months down the road, saying, "why on earth did I ever do that?"

Just my $0.02.

Answer 15

Checklists! They're not just for pilots:

The Power of the Checklist

Answer 16

A video of Dell's manufacturing plant inspired the architecture of a queue based distributed content aggregation system. A message on the queue represented workitems, with jobsheets, tasks, parts etc. passed from station to station.

Each station represented a specific stereotype of work, each station updated the jobsheet before forwarding the message back to routing for onward dispatch.

System is still in production 7 years after 1st release processing around 30K jobs per hour.

It was a thrilling moment to see the system "breath" for the 1st time.

Answer 17

Curiosity and tenacity.

Answer 18

While not exactly a profession, I think we also need to draw from the creative types. For example it's common for a writer to lock themselves away for blocks of time to write without interruption. Paul Graham draws strong parallels between Hackers and Painters