[Interest] What don't you like about Qt?

Roland Hughes roland at logikalsolutions.com
Sun Oct 16 03:08:44 CEST 2016


On 10/04/2016 06:31 PM, interest-request at qt-project.org wrote:
> I think the bigger issue, that many people have expressed here, but not said as such, is the Qt release cycle is not Agile.
I would thank God it is not, but the rest of your post proves that it is.
> As more teams adopt Agile development practices, the chasm between what user teams needs and what is being delivered grows.
Well, only teams working on products with the life span of a fruit fly, 
like a Web page. Most will be companies which go out of business. When 
one is developing things which will inevitably have a 30+ year life span 
or exist in a regulated environment Agile simply isn't an option. Think 
payroll, accounts receivable, and most medical devices. Yes, most 
medical devices in America are said to have a 7-10 year product life, 
but the "end of life" units inevitably get reconditioned and sold to 
poorer countries where they get used for another couple of decades.
> As a result, it seems that Qt is drifting away from what it's users want or need. Sometimes though, it's not even so much that we need release, we just need a patch to hold us over to the next release. My Agile team does two week sprints so we can reorder priorities twice a month. The Qt community has no say (AFAIK) in determining the priority status, or what is worked on when. The worst issue I know of as an example of this is the Canvas bug on iOS (https://bugreports.qt.io/browse/QTBUG-37095  ). It's been in there for 2.5_yeara_, 17 votes and 36 watchers. Which in my experience is pretty damn high, though there are older and higher ones. Use the search string "votes >= 17 AND status != Closed and type = Bug" to get a list of that
>    and it's brethren. Which brings up the question, why isn't the Qt staff using a similar search to prioritize their backlog on a regular basis?
This is inevitably what happens with Agile. Developers get to choose the 
stories (in this case bugs) they work on and it is way cooler to put 
your name on a new feature than to fix someone else's code, especially 
if there is a management team in place measuring "performance" by how 
many stories get completed each sprint instead of just how much better 
the end product is.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog




More information about the Interest mailing list