Google+ Badge

Tuesday, June 7, 2011

Programming solo on a development team is not easy

How do you code solo on a development team? If you are the only one who knows a technology and believe me it is not easy for necessarily fun. We have 5 developers on staff, one being the boss so he is also in meetings and what not. He takes care of various pieces of the infrastructure, a lot of the Jasper reports, database stuff and some Java coding. Two others do a lot of the Ruby on Rails work, DB work and some Java programming. The other guy does Java and a bit on the server side. For the first few months I was doing Java work on the Front end and a bit of Android work.

Now I am the one and only person that knows anything about iOS (which I learned on the job) to clean up the existing iOS app and to write the new one. I also wrote the Android port of the original iOS code. Others can help on the Android side and I can bounce ideas off them them as it is Java based. They can also do code reviews. My boss has written and published an app on the Android market outside of work as have I.

On the iOS side of things it is just me. No one can answer any iOS development questions, review my code or give ideas on how to make things look good on a small device. I can check stuff in that does not build and no one will notice. There are no checks and balances. I have a feeling this is a bit what it is like to work from home each day although even then you might have others in the company to look over your code and give suggestions.

It is getting to be a large chunk of code too. Over 500k of source code for a measly dozen screens most of them being some sort of table leading you to detail screen or to a data picker. There are also 17 SQLite tables with all the support code that goes along with that.

Before I began work here I had done a lot of work in C, C++, Java and C# with the most recent stuff in Java. I had not done any real SQL work and in fact got turned down for jobs because of that. For the small DB work I am doing it was really easy to pick up SQL. I am not dealing with stored procedures or a myriad of joins so I would in no way consider myself any sort of expert.

On the iOS side I have never owned a Mac or programmed in Objective C. It is a mix of C/C++ and Java so I was able to apply that knowledge to the task at and. I am not a big fan of Objective C or Xcode but it is serviceable. Someone needed to learn it and I volunteered for the task so here I sit. I have used a Mac before as I was the one at the previous jot to make sure all the Java code worked properly on the Mac.

I have never worked someplace where I was the only one that knew an isolate specific thing. Sure I have been the go to guy for an area of the code but it has always been in a language that others know. I was the TIFF and other image format guy at my last job but it was still just Java.

My wife and kids don't program so I can't go home and talk to them about it and now I sit at work and don't really have anyone to discuss my issues with either. Sure, I talk about the problems I am having but I just get blank stares. There is team interaction as I consume the data generated from the DB by the Ruby guys. We can talk XML format and all of that but I share no code with them. Objective C is a totally different world. I can't share any of the existing Java code. When I worked on the Android side I could share a lot of code making things go so much faster. Now it is all written from scratch and even though Objective C base language is just as terse as C the iOS API is not. I have manually converted a lot of Java code to Objective C.

Auto complete helps in Objective C but if you scroll though a file you will find it very dense. Parameters are named but without the big benefit of being able to put them in any order, default them or skip any you don't need. Easy to tell what you are passing but there is a lot of text. All strings start with @ which stinks. If that is the normal and not the exception then you should not have to type it over and over. This is a preprocessor for C thus it acts like a tacked on language syntax at times.

Programming for mobile devices is another difference. On a PC/Mac you tend to have a lot of pixels. Even if you code for 1024x768 you have a lot of room. Plus mice are pretty accurate where fingers are not. You need to leave big touch zones. Adding to the fun is lack of the standard 4 buttons found on the bottom of any Android device. Instead you have to add Menu, Back, Search support elsewhere in the interface. Home is there as the one big button you get on the iPhone. You have to break your UI into small chunks. Entering a date involves a full screen whereas on a PC you might have 10 dates on one screen in comboboxes.

You also deal with screen orientation changes. The Android side is easier here, design one screen in portrait and another in landscape, the system auto picks up the right one. Under Interface Builder you are really given no help. You can design two screens but you have to manually tie everything back into the code and swap views or skip IB move it all around in the code. Neither way is very friendly. UI items change size between the orientations too, the navigation bar is small as is any menu you may have added to the bottom of the screen. I forget to test landscape when running in the simulator, simple key combination to check, but then I realize I hosed something up when I hook up the device as it is easy and natural to rotate that.

This brings up the QA side of things. I have to get the code to them on a device and they need to check everything out in each orientation along with changing from one to the other and switching back and forth between screens. This is the type of thing you don't think about on the PC. We also have to worry about loss of connectivity. People on a PC tend to not lose the network connection unless something really bad happened. Laptops are a little more prone to a wireless loss but they still sit in place most of the time. I am working with Doctors who roam various facilities. I don't need an always on connection but I do need to communicate with the server from time to time.

I am writing so much code just to get the basics in place I am not doing a lot of testing. We are going to hit up QA and there are going to get a pile of new functionality all at once. This has not been an iterative process. With the Java code it is built as it is checked in. They can take a stable version at any time and test things. Can't do that with iOS due to many annoying limitations. First, you have to have a Mac. Our Java stuff builds under Linux and we run it on PCs, Macs and Linux machines. iOS apps have to be built on a Mac, the Mac has to have a developer license from Apple, and it can only be run on a device that has been provisioned for the developers license.

We can build the Android app with a developer license we create and it can be installed on any device via a command line tool to install the APK if you are USB connected to your PC, Mac or Linux box. I can also have any user run the emulator and play with the product without an actual device.

We only have one other Mac in house over in QA. I have to do all building, provisioning and installing. That is a waste of my time. The Apple way is just not developer or QA friendly. It really hurts us on the Sales demo side too. Much easier to send out a quick patch for the Android to a sales guy in the field. Nearly impossible to do on the iOS side. Plus we can never publish an actually release date for the iOS as we are at the mercy of Apple even though our program requires a login to our servers so it is stupid to have it in the App Store but the ad hoc distribution plan is not feasible. We are going Android on the demo and sales side to avoid the Apple hassles.

This covers a lot of ground but hardly touched the solo developer side. At times it is depressing. Working in a cave and doing a lot of Stack Overflow searching to get answers to questions. Writing reams and reams of code that only gets tested after months of work instead of weekly or at times daily. Needed to stop what I am doing to install the new build on a device and hoping when they drop by that I have a build that is currently stable enough to install. Not having people to bounce coding ideas off of means a lot of time under the headphones with my head in my hands. I am so ready to be back on the Android side where I can have people look at my code and tell me where I did something stupid.

I hope we are able to add another staff member at some point that can help on both sides of mobile development. I would really like someone to look over my code and find areas where I cheated or really screwed up. I can take the criticism and would feel much better with a second set of eyes on it and for someone to make sure what I am checking in builds on another system.