Quote:
Originally Posted by jgsmith
I'm not sure many people realize some of the complexities of software development. For example:
- Kobo has several devices, and each device requires both maintenance (support) and new features (development)...not just the Touch
- In order for the software to be manageable, I suspect Kobo tries to keep a single set of source code across all devices where possible. Having to add the same function to each device individually would be cost-prohibitive and would just get passed on to the consumer.
- Most software shops stick to a regular schedule for software releases. Time for requirements gathering (defects + new features); time to design the changes; time to develop the changes; time to test the changes internally; time to beta test the changes with the community. This all takes time. 3 months is very typical.
I've been working in software for 25 years, so I could go on...
|
Ah, a fellow developer.. I've been working in the field for 20 years myself and it's my experience that the users catch some things that I and the testers missed. I'm pretty sure you have the same experience if you've been doing it as long as you have. The point here is that it may be nitpicking but there are some things that have changed in the newest firmware that we have noticed and have voiced our opinion "It's not as comfortable to read as the previous version". Personally I don't mind that the top margin CAN be touching the top. I would then like the option to SET that top margin larger like I am able with the side margins.
To cover your points:
1) It is true they have several devices that require support and development. It may be just me but you seem to assume that there is only one or two development groups that cover multiple platforms. That may be true, but I would think it would be more likely to have teams that focused on certain 'groups'. E.g. Linux based (all Kobo readers), mobile based (Android/iOS/etc.), and desktop/Web-based (Win/MacOS/HTML5?).
2) I don't think they have a single set of source code, unless it is that part that deals with the Kobo servers. All other code appears at this point to be specific to the device. Can you honestly tell us that you believe that the UI and features across all the OSes and devices Kobo supports is that similar? Even between Kobo's own devices the UI and features are not. As you point out it would be cost-prohibitive but from all appearances, that is exactly what Kobo is doing. It may be more likely they have (similar to my comment above) certain 'groups' of source code.
3) Yes, I understand time is required for all those phases. I just feel that there should be some community input in the first phase to avoid any large complaints about new features later. e.g. the 5 thumbnail listing on the HOME page. As a developer you are ultimately developing for the User, management may have it's ideas and push through most of them but if it ends in a low UX users will eventually move on. If you've read these forums for very long you see that happening quite often. Would it not be to your and management's benefit to know what the target audience wants and not just force it on them? Also as a developer you must experience times when you will not make the deadline due to unforseen delays or problems. Do you delay the product further or do you cut out/postpone features till a future update. Kobo I believe has leaned towards the former but seeing as how long it has been since the previous update, have finally decided on releasing minus some planned features like the 'collections'. Yes, 3 months is typical, but for kobo their track record was a bit more frequent.