After a year of work, a companion app to Jordan Rudess’ new solo piano album All That Is Now, is available in the iOS app store.
Developed by Jordan and myself, Jordan Rudess Explores the Music of All That is Now invites you to do more than listen to Jordan’s amazing new solo piano recordings; rich visualizations, atmospheric accompaniments, and unearthly sonic effects will all be at your fingertips. Journey deep inside these beautifully composed pieces as you discover your own unique musical experience, then share it with your friends.
Jeff Miller of JM Creative is the UX/Visual Designer behind the stunning look and feel of the app.
This year I attended WWDC after not having attended for close to 20 years – although I’ve been programming the Mac (and iOS) regularly throughout that time. Here are some observations as memory serves from 20 years ago:
- It was in San Jose
- It was myself and maybe a couple hundred others
- It was friendly and fun
- Super intelligent and creative people
Here are my observations as memory serves from this past week:
- It was in San Francisco
- It was myself and 5000? 6000? others
- It was friendly and fun
- Super intelligent and creative people
But allow me to continue on about this year:
- I was completely amazed by the number of first timers (2/3 was the number I heard)
- I met people I knew online for years for the first time in person and took those friendships to new levels
- I re-met people I haven’t seen in person for years and solidified those friendships
- I met new friends from over a dozen countries – all it took was a simple “hello” to kick things off
- Some of the first-timers came alone to the US for the first time and were fulfilling their dream to come to WWDC – that’s pretty powerful
- At least twice when I mentioned my having been there 20 years ago the person I mentioned it to admitted they were 5 or 6 years old – if even born – at that time!
- The new tech is excellent!
- Everyone was very excited this year
- Everyone shared and freely spoke about their projects and when asked how they did something in an app never hesitated to share the technical details – we were not competitors – we were all in the same boat helping one another
- People were working on some unique, amazing things
- Every Apple engineer I spoke with was very receptive and willing to help in any way they could
- The few “big wigs” I got a chance to say hello to were very approachable and friendly – even though they were forced to wear collared shirts
- The event organizers were super helpful and put on an excellent event making sure we had coffee and snacks when needed
- People were really good about standing in lines and letting others “cut in” when they saw friends – I was never in a line that forced me to not see a session or event – it was more for order – and everyone seemed very relaxed about the whole situation
- Even the manager at the local Apple Store was interested in how we were doing and was super helpful in making sure they had stock of the much-forgotten-at-home USB/Thunderbolt Ethernet adapters – Apple “brought it” from every angle.
To sum it up – camaraderie, friendship, openness and a willingness to support those (young and old) honing their craft of building amazing apps for Apple products and a new generation of OS. WWDC 2013 was absolutely excellent! Thanks, Apple! Steve would be proud. I can’t wait to see what the next few months bring!
The project has multiple facets that revolve around Jordan’s music for both solo piano & keyboard and orchestra.
One component of the project is his new solo piano release entitled “Explores”. This beautifully recorded music will be released as a completely interactive iOS app experience in addition to being made available in CD and digital download format. Listeners will be able to use gestures to interact with the audio and visuals and create their own versions of his music. We are incorporating some of the latest iOS audio and graphics technology to make this app the absolute best it can be.
Jordan and I have been discussing for months about the possibilities for this project and are happy to finally present it as a Pledge Music campaign that allows Jordan’s (and my ) fans to pledge their support and receive some great rewards in the process. It’s great to see how many supporters are already onboard and excited about this work. Jordan will be giving regular updates on the status of the project with posts and video demos.
For more information, project updates and to get involved please visit the campaign site.
I’ve been estimating work for over a quarter century. That make me sound like an old furniture store that should be one of the last places to close their doors in your hometown’s downtown – or “uptown” depending on where you’re from. As an independent software developer (and really in just about every “real” job I’ve ever had ) estimating time and/or effort is very important. A client wants an estimate that is realistic – and so do you – lest you work too much for too little or tick off your client with hidden costs that seemingly spring out of nowhere.
Estimating is a very personal thing. Everyone works at a different pace. Your estimate has to take into account your experience (or lack thereof) on the given project. Even if you plan on offering a fixed cost for a project, you should probably spend the time figuring out exactly how long it’s going to take you. You might be surprised to find there is more to it than you initially thought once you start listing tasks.
What follows is the way I do it. It might not work for you. I try to strike a balance between too much detail (which I personally think you can’t know in many cases until you’re actually writing code) and too many gaps. Gaps are bad in a project plan and estimate. They mean you neglected to account for something. You don’t know about a gap until you’re right up on it, then you need to be careful not to fall in!
The first thing I do when a client comes to me is talk with them about their project. Whether it be via phone, Skype or in person – I try to get as much information about their vision as possible. Some clients know exactly what they want – others want you to help them decide – others are in the middle. During this conversation I usually toss back ideas and see how they react. Point them to various other applications that might have features similar to theirs or ways of doing things that are interesting. This helps me to gauge if we are on the same page (or in the same chapter – or even the same book!) and helps to decide what direction we need to move to bring things together.
Once I have a pretty solid idea of what the client wants I create two documents. The first is the technical specification and the second is the estimate. I work on these documents in parallel.
The technical specification is a word processing document that allows me to capture everything we discussed in our conversation(s) and essentially outline – mainly with wireframes – how the application will function, where it will get its data, where it will save its data and everything else that goes along with the project. The specification is solid enough to agree that this is the way it should be. It is not in stone. It has small, known, manageable gaps. The kinds of things that you deal with when you’re actually writing code – like – what should the exact rectangle of a button be. Those types of details are not needed at this stage.
The estimate is a spreadsheet. As I work through the various pieces of the technical specification, I make line items (first course, then getting more granular) for the various pieces of the application. I rarely add anything to the estimate that takes less than 15 minutes. I’m not going to list things like “round the corners on the button.” That stuff takes mere moments and in my opinion falls under other larger entries such as “design look and feel.” The estimate for a small view might be as simple as:
- Implement base view UI (based on a wireframe, obviously) [2 hours]
- Integrate Core Data store into fields [.5 hours]
- Display custom chart [1 hour]
That’s it! The client doesn’t care about all the minute steps that are really taken to tweak frame rectangles, etc. But at the same time, they need to see that you’ve thought through the work to be done. More importantly – this helps you think through the work to be done! Typing it out, walking through the UI in your mind, iterating, this all helps to make for a better specification, a better estimate and ultimately a better product. You’ll still write and rewrite certain bits of code multiple times to make them “just right” but that just goes with the territory.
When it comes to the numbers I have a pretty simple way to deal with this. As I already mentioned, I don’t list things that ultimately don’t matter – in most cases this means things that only take a few minutes. Mind you, if you have to repeat a task 1000 times then you might list the entirety of the task as a unit of work. So the first thing is I manage which items I actually put on my estimate. Next, the items I *do* put on I break down very simply…I figure out which of the following chunks of time the work best fits in:
- 15 minutes (real quick)
- 30 minutes (pretty quick)
- an hour (sorta quick)
- 2 hours (half a morning, half an afternoon, post-dinner but before bed)
- 4 hours (a morning or an afternoon)
- 8 hours (a full day)
- 10 hours (a day and some time the next morning to verify)
- 12 hours (a day and a half)
- 16 hours (2 days)
- 20 hours (a half of a week)
- 24 hours (3 days)
- 32 hours (almost a week)
- 40 hours (a week)
Anything longer than a week is usually split into multiple items unless it’s just some obvious thing (ie: design meetings) that is going to take more time.
Once I get all of the line items broken up into times like this, I can hone in and make adjustments where necessary. The bottom line, if something will ACTUALLY take you 90 minutes – it’s OK to put 2 hours on your estimate. You will likely encounter hours upon hours of bug hunting or research into making a new technology work properly so these small pads are expected and part of the process. As long as you track your time reliably it will all turn out OK in the end. Remember, this is an estimate.
Once the client accepts the proposal and estimate I follow the spreadsheet and fill in the actual hours in a column right next to the estimated hours. I keep a running total and settle discrepenacies with the client at specific milestones or at the end of the project depending on how they are choosing to pay. Every project and every client is different so adjustments are made as needed but this technique has worked really well for me for many years and has allowed me to stay within my client’s budget and within my estimate more times than not.
Reliable estimates make for happy clients and happy clients make for happy you.
I’ve been thinking about how I work lately and have a pretty good idea of my strengths and weaknesses. When it comes to writing iOS apps specifically I’ve found a really good groove that works well for me that I wanted to pass on here.
This is one of those chicken and egg problems in a way but lends itself well to the iterative nature of iOS development. I need to do something the night before to be ready for the next day and I have to get things done during the day to be able to do what needs to be done at night. I’ll start in the morning but it’s basically a loop that you have to just jump into.
You have to have a plan for the day. Today mine is: “Morning Plan: finish implementing a C++ audio base class for sample processors. Afternoon Plan: write a few more processors using this new architecture.” The plan needs to be simple. If it contains too much detail it’s easy to lose site of it. Now I know what I’m doing and if I get sidetracked I can easily point myself back to my plan.
AN ASIDE: THIS IS HOW YOU SPELL LOSE – pronounced LOOZE. LOOSE is the opposite of TIGHT. LOSE means to fail to retain. But I digress. #petpeeve #798
So I go about my work during the day, getting things done, and doing my best to get my code to a relatively stable point. Now, before I’m done for the day, and this is the key, I install the app on my device! Simple enough task. Now I have the rest of the evening, little moments here and there and while settling down for sleep to play with the app. As I use the app I notice little things. This view doesn’t feel right. That button isn’t as responsive as I had hoped. Something is off by a few pixels. There is a glitch in the audio. It doesn’t work right when a phone call interrupts the app. All of these things I make a note of – I happen to use Evernote and Things for this but mental notes or simple sticky notes will suffice.
If you say “play with the app” it doesn’t sound like testing – but it is
The idea is as I’m playing with the app and finding these issues, and ultimately setting my device down and going to sleep, I’m thinking about my plan for the next day. What needs to be addressed. What needs to be tweaked. I can think through some of the problems I’ve found and how to address them. Many times I can work through issues so when I get to Xcode in the morning it’s just a matter of typing – I’ve already done the hard part – the thinking part. Sometimes this doesn’t always work out but when it does it can save a ton of time and make me ultimately more productive.
So that’s really it…code…build…install…play…think…repeat…