Tag 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.

Tab bar or no Tab bar?

Interesting writeup from Justin Williams about the use of Tab Bars in iPhone development. One of his big gripes is related to the space the tabbar uses:

When I made the decision, my thinking was that the application had four separate features, so it only made sense to separate them using the tab bar. What I found as I got further into the development of the application was that the bottom tab bar was incredibly limiting for where to place extra controls.

The main problem here is that by default a Tab Bar is visible in all views of the application. I much prefer Tweetie‘s implementation, where the tab bar is only visible on list views, and pushed away on the detail views. Of course, this layout is actively discouraged by Apple, who recommend you put your navigation controller *inside* each tab bar. They do it the opposite way themselves in itunes tho.

Also, the interaction allowed by the Tab bar is really limited. You cannot easily disable and enable a tab, for instance. Still, I believe this way of presenting data has merit, specially in giving non-technical users a clear overview of the main parts of your application.

*update* As Ross Boucher points out you can also hide the Tab Bar by setting the “hidesBottomBarWhenPushed” property on your controllers. An important gotcha with this is to make sure you only set it on the first level controllers.

TextMate 2: It’s coming

Allan Odgaard reassures us that TextMate 2 isn’t going to be a Duke Nukem Forever:

So where does development stand for 2.0? It feels to me like most of the modules are getting close, say 90%. But as they say, on the horizon, mountains look small.

I guess he just has the remaining 90% to finish. :) I for one think this is exciting news. TextMate is probably my second most used program after Firefox.

GitHub:FI pricing now public

GitHub created a headache for themselves at the initial launch of their inhouse hosting option for companies wanting to use GitHub.

That, coupled with the fact that we wanted companies to sign an NDA before receiving their quote, slowed the entire process down. It also bewildered more than a few people wondering why lawyers needed to be involved just to figure out how much the product cost.

Well, now they are up for everybody to see, but boy, with prices like that, I can see why they would like to keep them secret. $600/user/year. First year up front. For us, having 5 accounts, which is what we get with their ‘Small’ plan, it would be an upgrade from 144 USD to 7200 USD per year. After the first year we’d have to add 750$ a year if we want standard support. I doubt this is a very viable plan for most development shops. Specially considering Gitorious is open source.

Copyright © marcus ramberg
nordaaker

Built on Notes Blog Core
Powered by WordPress