Quote:
Originally Posted by PeterT
Remember; it's not as if the PROGRAMMERS normally have any say in how the layout looks on the device.
|
Quote:
Originally Posted by Rugalb
So you are telling me that they keep that disgraceful blank space and that awful long paragraph bug because they like the way it looks? They should allow the user more customisation IMHO.
|
No, it means they have decided they know what is better for the device they are selling. Just like you have decided that you know what is better.
And Peter emphasised the word "PROGRAMMERS" for a reason. A programmer on a large project rarely has a say in what gets implemented. They get a task that says "implement this". How much detail they get depends on how the project is run and the actual programmer. A junior programmer might get it spelt out almost to the code level. A senior programmer will get more freedom. But that freedom will be to design something to a defined set of specifications. The programmer might be able to change some things, but will usually need to put these back through the change control process to get the are accepted.
I'll make a comment on the "Kobo should add these as options" that is everyone's opinion. That isn't as easy as it sounds. And adding options to existing code can be even harder. If we add a new option, say one to not display the title in kepubs, this is what needs to be done:
- Decide where to display the option
- Word the text and any help for the option
- Add code to read and save the option as part of the settings
- Add code to use the option
- Unit test the change to make sure it does what is intended
- Test the change as part of the product to make sure it works and doesn't break something else
The above is a simplification. And the first two steps are a lot more important than you think and can lead to a lot of discussion in the development team.
The testing is also a problem. Adding the option suddenly doubles the testing of that module. They need to test with the option set and without. If they also added an option to hide the page number, there is suddenly four combinations to test.
All the above means that adding features to an existing code base is not as simple as it might seem.
Bug fixes are usually handled differently. Someone gets a list of reported bugs, tests them to see if they can be reproduced, verifies they are actually bugs (the widows and orphans handling is not a bug, but the long paragraph handling is) and then prioritises them. Then, they are handed to the programmers to fix the bugs in order of priority. The highest priority bugs will always be "can't use the system" or data loss. As annoying as the long paragraph bug is, it will be a low priority. The book can still be read but will need a few more page turns.
Should Kobo hire the author of the patcher? I have no idea. What he is doing doesn't necessarily demonstrate any programming skills. It demonstrates the ability to read the compiled code and work out what can be changed. That is an impressive feat, but doesn't actually say the author can write code in the language that Kobo develops in.