One of the most common scenarios I see is companies using Excel to run their core business. Whenever a new report is needed, new analysis, new form, data conversion, no matter the task, they turn to Excel. They make everything look like a nail, and the only tool they understand is Excel, so they use it like a hammer. The result? Manual processes, inconsistent data, key-person dependencies, inflexibility, pain and suffering.
I have just spent the past few weeks working on the initial design of a new product for Noverse. The question was how to deliver the solution to our customers. We could: Install it on their infrastructure - lets call that the “Corporate Model” Deliver a prebuilt computer with the software on it - lets call that the “Appliance Model” Host it on our gear accessible over the internet - lets call it the “Hosted Model” Lets look at each in turn.
In many of my articles, I talk about the Software Designer, I even call myself one. But what does this mythical person do? Are they a graphics designer? An architect? A consultant? A software designer is an individual who has the vision, passion, communication, understanding, flexibility and process to generate software form; and make the necessary decisions about what, when, where and how in development. Note that the designer does not necessarily conceptualize the idea.
With apologies to the movie A Few Good Men, 1992, directed by Rob Reiner. The right team size for software development. How many people does it take to develop a Software Product? How big a team will I need to create to tools for my business? I need to migrate this legacy software to a new platform, how many programmers will I need? These are common questions asked of CTO’s, IT Consultants, startups, techies and, of course, me.
This question was asked, and answered, on stackoverflow.com 2 years ago, and has been viewed almost 200,000 times. I was one of the people who answered the question (click here). There are three components in almost every iPhone app: a server component, a design component and an app component. Server Component The server component of an iPhone app usually takes the most effort and chews up the majority of the budget.
The waterfall model for software development has gone the way of the dodo (and did so at about the same time). Yet this newly minted indie developer often gets requests for proposals that follow this model, fixed-time, fixed-process and fixed-price. I instantly and politely decline these requests. I don’t ever want to decline work, and when I set up this business, I planned to say yes to every potential client and service them as best as possible.
Sprint Coding is the process whereby a skilled programmer busts out a quality application in record time. Its not easy. Fast coding means faster bugs. Quick coding means rotten quality. Rapid development means architecture is ignored. Cowboy coding produces unmaintainable code. In short, I don’t recommend it. But, my dear padawan, it is do-able under the right circumstances. Rare circumstances. Recommend this, I do not. Scenario, this is. A client called up at the beginning of October and asked if I could produce an iPhone app for them.
The iPad version of Sights to See is coming along nicely. All the views have been strung together and I’m starting to work on the details and aesthetics. Here are a few screenshots to whet your appetite. When you start the app, you’ll see a world map with all your guides on it. I am also experimenting with a ’tag cloud" approach to help you jump to a guide quickly, but it may not make it into the final product.
I was having a discussion the other day about my next OS X application and the responses I got were that there was a free web way or a free command line way to do what my app will do, so why bother? It got me thinking about how I use software, how other people use software, how people tell me how to use software and how I tell other people how to use software.
Real programmers ship. I did, ten days ago, into the App Store review process. And now I have the postnatal shipping blues. The blues come from two sources, shipping and waiting. shipping blues The first version of an application always ships, if you do it right, with the critical core features working, one or two bells and whistles to make it fun and nothing else. Do any more, and you’ll never ship.