I am working on a contract currently where they developed an iPhone app first to prove out the server side API. There are 6 developers on the iOS side of the house. They brought in me and another Android developer that I had worked with in the past making for a pretty solid team right off the bat. They expected us to be 3 months behind the iOS team as we are out numbered 3 to 1 giving them plenty of time to shake out all the issues and solidify the core design.
We have run into a multiple issues. First we have already caught up with the iOS team. Most on that team were C# developers reassigned to Objective C. The other Android developer and I came in with a decent background in Android development. Of course that allowed us to quickly catch up as we are not learning Java and the Android SDK, we just need to buckle down and code.
Since I have also done iOS development and I have access to the Objective C code base I have looked it over. The code does not look like Objective C. It looks like someone tried to force fit one language, C# in this case, into another language. Macros to emulate methods of C#, no method definitions in the .H files, everything stuffed into dictionaries when other collections make more sense and a number of other issues that would drive a person who lives in Xcode bonkers. The code is very hard to read as it is not what you expect to see when you view Objective C code.
One of the steps we took in the process was to print out the screen shots, four to a page, from the user stories and cut them out. We saved paper but still gave us enough room to make notes. This allowed us to see the big picture of the project and divvy up the work of creating the screens in XML. The best thing it allowed us to do was find inconsistencies in the layouts. Did the date appear above the amount on one screen but below it on another? That happened in various places. Was it called Transaction ID here and Confirmation ID there? Yes it was.
We were also able to find screen layout patterns and create generic layouts in code. We grouped all the screen shots of like type together and decided where we could use a generic layout to handle things. This let us start with a solid initial set of activities and fragments. We also looked for areas to share Action Bar code. We were able to quickly get fragments and activities in place.
What happened next is where things did not work out. Even though the company follows a flavor of Agile we were stuck in Waterfall. The product manager did not want to change any of the user stories on the iOS side even though he admitted they are wrong. He just wanted the Android team to follow the iOS design, inconsistent as it is, because if he changed a story he got in trouble.
There are various aspects of the project that look like this is the first attempt of a web designer on a mobile device and this is exactly what happened. Another reassigned person who did not put in the effort to really learn the new platform they were tasked to work on. The project looks ugly and out of place on the iPhone and even worse on the Android as it got a second level of ugly being a basic conversion from the iPhone. We were able to argue and remove the iPhone specific look and make it at least appear to be an Android application but we are struggling to get them to fix the consistency issues and to remove unneeded screens via a much cleaner interface.
Yes, they see and agree with our suggestions but they don't want to take the time to update the iOS user stories and screen shots or have that team change the code. The iOS team is willing to put in the work. The project is no where near shipping as the server side API is not finished. In fact it is all still mock data. The server is not talking end to end to the real data providers yet so this is the perfect time to clean up the user interface on both applications.
When I speak with the iOS team they admit they gave up long ago. Just code and layout what was given to them by the UI team. In the Sprint meetings they did not bring up all the areas they felt were wrong on the iOS design. Dialogs that are justified to the top of the screen instead of centered. Hand drawn buttons where the iOS button looked nearly the same, extra screens and taps to get the where you needed to be, data displayed in the wrong order. They have been at the company for so long they just accept and do what is told of them.
There are so many other things wrong on the iOS side I can barely stand to run the app. The keyboard covers the entry field so you can't even see what you are typing. I have no idea how this made it past QA let alone how the developer thought something that basic was good enough to toss over the wall to QA. Table data was hand laid out in Interface Builder and they did not space it evenly. A label is not base aligned with the data to its right. The don't have the back button on all screens. They don't support landscape except on one screen where they manually rotate the objects they paint to make it look landscape even though it really is not and you can tell that by the look of the main status bar.
I do run the iOS app as I want to make sure we are not missing a screen or dialog on the Android side. I have found various areas that are not in sync because it was not called out in our user stories. The user were copied over from the iOS Sprints to the Android Sprints. This means the iOS QA team also did not report issues when doing their work.
Luckily for us we have an Android QA person that also cares and calls out the issues and wants this to look as nice as possible on the Android platform. That is a huge help. Since we are highly outnumbered it is good to have one more in our camp.
Another issue we have is QA is under one manager. Development under another and Product Management / UI under yet another. All we can do as developers is make suggestions to our boss to make suggestions to QA and PM bosses to try and fix things. There is no accountability in place and things are falling apart. The UI and product manager have been with the company the longest and are very closed to suggestions.
To me the product manager should have the most pride in the application. He should want it to look the best on both platforms and fight to the bitter end to see that happen. Instead he just shrugs his shoulders and gives up. It is very sad indeed. He has put the Android team into waterfall mode, don't question anything, just do what they did on the iOS side, as long as they match it is easy to support. I know it does not look like an Android or an iOS app but it is better than the previous release which was a WebView wrapper around the main web site. That part is true, it does look a ton better than it used to but with some small tweaks it could be a stellar application.
I did get the PM to agree to a number of consistency changes. Then he came back in and told me to back out all of those changes to make it match the iOS side even though he knows that side is wrong. This is the part that is killing me as a developer that takes pride in his work. Look, the code changes are not tough to reverse but that is not the point. I know I will be releasing at some point in the future an inferior product. I am a contractor, I will have to do what the company wants but boy does it hurt.
The next and final missing Android area of the product I will be working on hits sizing meetings next week. I am dreading these meetings as we have a new design in mind that eliminates 3 of the 7 screens in the current iOS design. The design we are suggesting makes it work like the Google supplied application on every Android phone. I sat down with the iOS team that wrote that area and they really like the new design. They are more than willing to change the iOS side to match it and agree it will match what an iOS user would expect to do instead of the web interface look that was provided by the UI and PM teams. I have a feeling I just get to shut up and roll over on Monday. Add to the fact one of the iOS developers who worked on this area resigned last week. While I have not had the chance to speak with him directly my guess is he was sorely disappointed with how the company operates too. He converted from contractor to perm employee just over a month back.
They don't want an architect or a leader. They want a faithful dog. I am not a dog. They pitched the position as an architect position where I was Android voice for the company. All I can hope for is my next stint does not have all of these issues, that they follow a truer flavor of agile or at least stick with one design pattern. I was told I was brought on to do the best Android product possible but that simply is not the case. It is such a struggle to not be true to myself when I am developing this code. I will do the absolute best I can for as long as I am there, that is who I am.
Great news, about the strong programming with the team . There are reputed iPhone development companies who are continuously doing research on the customer's needs , and then they produce the results.
ReplyDeleteiphone application development