Tag Software development

Makers

You can start making something in seconds.
One simple idea is all you need before your brain
automatically explores problems, solutions, and dreams.
Turning that idea into something tangible and wonderful is harder.
You need structure, strategies, people, hard work.

The software world is young and we are still figuring out the most basic processes of the craft. For instance, we tend to label ourself architects or designers, inspired by people who build houses or work in mass production.

Designers tend to paint pictures, while engineers tend to make diagrams describing what they want to make. Both of these approaches are fundamentally flawed in software. They make a lot of sense in the trades that inspired them, where the cost of change is high and getting it right the first time is essential. Making software is pretty much the opposite.

With software it’s so easy to reiterate that there’s no need to choose between ideas on the drawing board. You can simply build it and see for yourself how it would work. As long as you always make the simplest possible version, you can quickly verify if it’s a good idea or not, and it can be rather efficient too.

I’m not saying that you shouldn’t use Photoshop or OmniGraffle in the process of making. They are useful tools for making your software better. Refining it, making sure they play well with others. However, I believe that a lot of the
‘design processes’ that go on now are flawed.

In fact, I would like to remove all labels. Take a big magic marker, cross out ‘engineer’ or ‘designer’, and write one word on all of them:

MAKER

I sometimes hear people say ‘everything is design’. I do agree that everyone who is involved in making software needs to care about what it does, how it works, how it feels, and so on. The problem in my mind is that this definition
makes ‘design’ too generic.

It also tends to exclude programmers and gives the impression that they don’t need to care about the look and behaviour of the end result. In my experience, this pattern leads to massive amounts of suck.

Stop thinking about programmers and designers. We’re all makers, so don’t feel limited by such a poorly placed label. You’re job is to make the software. I don’t care what hats you wear as long as you’re contributing. We should always strive to learn more skills, to become better makers.

People with a classic IT background should learn more about writing, colors and traditional design principles. Those who possess these skills should learn more about markup, CSS, Interface Builder, or maintaining resources in version control systems and project files. The more you know about how software is made, the better you can help making it great.

This does not mean that I advocate design by committee. I do believe all software needs a director; one who maintains the vision of what we are making, and who instructs and directs the rest of the team. This person is ultimately
responsible for the shape of the product. But without good makers, that person is doomed to fail.

Let us all become better makers.

Even Enterprise thinks enterprise sucks

Early in my career I worked for a large telco at. The term “Enterprise Software” still gives me me chills down the spine. Likewise terms like WS-* and SOA, which for me represents huge amounts of bloat and hatefulness.

This is in fact one of the reasons I prefer working in smaller more agile shops. Apparently, I’m not alone in disliking enterprise software. Software AG’s “Chief Strategist” Miko Matsumura sums it up well:

Working with Enterprise Software feels a bit like walking through an industrial landfill or an airport hangar. Nothing is built to human scale.

Lessons from distributed software development

I found this very interesting, and some of his experiences rang very true to me. Nordaaker’s experiences with distributed software development so far has been fairly positive, but it does require a different mind set. In particular I do agree that followers of agile software development will have to adjust.

On think that I absolutely agree with but find it hard to sell in to clients is the ‘do not estimate’ policy. Clients like to have an artificial idea of when their product will be done/what it’ll cost, but the fact is that an accurate estimate is very hard to accomplish, and a thorough attempt will cost more than it’s worth.

Copyright © marcus ramberg
nordaaker

Built on Notes Blog Core
Powered by WordPress