What I'm actually doing here is something called "narrative capture":
Rather than have everyone say what they think wastes their time (biased), I'm looking for recent stories and correlating the results. Much harder to unconsciously game.
Of course a bit of fieldwork with every one jotting down what they are doing every couple of hours would be better, but having some alarm go off four times a day could get a little disruptive.
So far not much to go on, but here are the scores so far...
4 mentions: Repetition, Refactoring own code.
3 mentions: Exploring new ideas/tools, Lack of readable code and bad naming.
2 mentions: No docs, No tests, Writing docs, Client communication, Overdesign, Lack of identity map, Evaluating 3rd party code, Magic routing, Trying to find code, Rewriting distrusted code.
The singles are even less significant: Tendency to be "smart", Mixing languages together, Writing tests, Too much in a method, sprintf(), Non standard error reporting, Registry, Changing session variables, Task handover, Pointless marshalling, No version control, Boss distrusts open source, Campaigning for better practices, Bad bespoke frameworks, Flakey API, Waiting for provider, Planning, No deployment process.
Any ideas on how to group the data?
Need more stories here people - please help. I'll N-gram all the posts if we get a few more.
Currently we are stripping out our current view generation layer and making the themes directory configurable. The old browser driver mocked driving the browser using debug but this is no longer needed as we have a selenium adaptor to run the old tests. The old method relied on swing like widgets to generate debug that the test runner used to validate usage. Like a lot of widget systems it relies too heavily on inheritance( 4-5 levels deep ) and ends up being a code merry go round. The code really sucks in the views as well.1) What is the last non-feature thing you did? Could be right now, ten minutes ago or whatever. However small.
I have been playing with this for a fortnight now making the theme directory configurable( 3000 theme files ) involving 500 file changes( though admittedely some structural indulgance such as adding interfaces to make publicity more followable ).
Without the high test coverage at all levels (plsql/php/browser) the lack of clarity in the evolved design would probably ear mark it for termination. Too obtuse, never know what will blow up.
Mostly network stuff and cvs playing buggers. 2 days to merge and commit. Hardware currently is remote and we are looking to get a local oracle server and web server.2) What was the biggest hold up so far this week? Something where you were out of action for 2 hours plus. A bad rollout, difficult bug, training, working around a framework, figuring out how something poorly documented worked, a long meeting. Anything you want, but at least a couple of hours of delay. Name and shame dud libraries.
1. Really sucky error handling. This is evident in a lot of projects (such as the code for stagehands autoloader just tries/or just used to include the file failing silently) leaving an xClass does not exist message with no include path showing etc. Those sort of autoloaders are worse than require once by a mile. That sort of error handling is rife and leads to a game of var_dump through the code base. When I find something I add a thrown exception with a meaningful friendly explanative message so if it does occur again it is traceable. Each thing should only make 1 person pay the cost of chasing their tale for everyone. If you chase your tale and do not try to help the next person you are part of the problem.3) What typically wases your time? You can rant on this one.
2. Over reliance on a registry for communication. Hashmaps are getting pretty much banned as like registries in their rawest form they lack design in their interface. Large code bases are much more sensitive about communication in their design and using bucket approaches is just lazy. var_dump/print_r should not be an often used necessity. It is boring and lazy.
3. Unit testing done wrong. With a code base where 10+ peoples ideas of unit testing cohabit there is some real just plain badly written tests. I have followed the agile community quite closely on this as the claim is it speeds up development which it can do if the the code follows the single responsibility principle and the objects are light. What starts out at 1.2 or so lines of test per line of code can end up at 6+ lines of test per line of code. Get given a small change and the forcible choice is refactor getting this fatness down of have to create 400 lines of uninteligable meandering mutterings of assertions. And we are talking about a small little 'if' here and an extra parameter not anything major.
I believe if a test is not readable it is partially worthless, it also likely has holes in it.
I think there is a metric somewhere if you hit two lines of test per line of production code then it is time to analyze design and maybe have a rethink. It will only get worse over time without diligence, if you have to rely on others for it the bigger the team the more bad design gets reproduced in all the monkey see monkey do.
I like unit testing, it leaves things maintainable. Whether it is a dog to maintain is another metric. I like the Boy Scout rule (http://www.informit.com/articles/art...35624&seqNum=6) but it is something everyone has to adhere to otherwise it is like swimming upstream.
It might sound like hard work but I moved to a new team that is branched off so this stuff can be tackled. Before hand it was 10+ projects all on branches of the framework with no hope of being merged in. Each new project duplicating the design errors of the past. Make an improvement and then make it another 9 times while 9 other people repeat the same pattern of what has been removed.
Current project plan is to remove the duplication of effort as it kills productivity stone dead. 3.5 load factor is acceptable but is currently 6+, getting it back to 3.5 is a nice challenge.
Without a bit of pain this job would be boring, as long as that point of pain is not repeated over and over and is marked for death at some point it is manageable. I give things a few years of effort though before starting to mentally mark points of stagnation down heavily leading me to move.
Even though a large part of the issue is the framework design without some precedent of design it would further resemble chimps scatting. The code before framework and TDD is just locked away where only a few people are allowed to touch it. PHP 4.2.4, register global variables, all the best old school type of PHP party where the motto is “I want to do it MY way and I want to do it NOW and it will look like the creation of someone on too much methamphetamine as that is an accurate representation of my genius. My genius is just not understood, only I can code this byzantine. I AM L33T”
It is quite a good and sanitising game working out what drug consumption would produce certain pieces of code.
play my guitar (11mb) probably... Music is another thing, like programming, which can devour all your time.
Work related: subscribers who can't log in. It usually turns out they just forgot their proper password but I still have to go on red alert painstakingly checking through the code for bugs which don't exist, manually checking every new subscription as it comes in, and so on.
It's not a regular problem though. In fact, I very rarely feel that my time is being wasted. I get on well with my client - I sometimes spend New Year with him and his family - so I guess that helps. It's a small team of two and I think we both appreciate what the other is doing.
Sorry Marcus, skipping right to this one to rant. My biggest waste is actually NOT being able to use PHP because it is not an "accepted standard architecture". Stuff I can kick out in PHP in a few hours on the weekend takes my team weeks to do in the proprietary "compile to several version old flash" tool that is part of the accepted architecture. And then changes take 10 times as long as well Probably not the angle you were looking for in this thread though.Originally Posted by lastcraft
4 mentions: Repetition, Refactoring own code.
3 mentions: Exploring new ideas/tools, Lack of readable code and bad naming, Missing tests.
2 mentions: No docs, Writing docs, Client communication, Overdesign, Lack of identity map, Evaluating 3rd party code, Magic routing, Trying to find code, Rewriting distrusted code, No version control, Non standard error reporting, Registry pattern.
Single mentions in waiting: Tendency to be "smart", Mixing languages together, Writing tests, Too much in a method, sprintf(), Changing session variables, Task handover, Pointless marshalling, Boss distrusts open source, Campaigning for better practices, Bad bespoke frameworks, Flakey API, Waiting for provider, Planning, No deployment process, Not being able to use PHP, Users can't login, Excessive inheritance, Slow remote infrastructure, Bad tests, Multiple projects in one repo.
Some real gems are appearing in the two hits category. Keep 'em coming people. If you've already posted and hit something nasty over the next few days, I'll include that too.
What's worse is that by taking over such jobs as configuration, environment (machine differences), instantiation and dependency management for every possible use case, setting up the framework gets so convoluted you have no hope of internalising it.
That forces you to grep everywhere. If the setup throws an exception, don't expect a stack trace to make any sense.
Combine that with a universal base class and you can say goodbye to print_r() as well, not to mention you now depend on half of your app plus an entire framework. Take over autoload for the final dash of confusion.
That's true genius.
You can't figure out what's been instantiated, you don't know what parameters it received, you can't print_r() it, you've no idea where it came from and if you do find out, you daren't fix it anyway .
Gah I just wrote a really long post about stats, then sitepoint went down temporarily!
I don't know what you're trying to achieve here but you need to be careful with any conclusions you make. Firstly, the sample size is so small you can't really claim anything is statistically significat. Secondly, as with any survey, you can't judge how people rate "time wasting" what one person mentions as highly important, someone else may consider insignificant. Finally, you have the "me too" problem. Because it's an open survey people will read the answers and naturally get reminded of an issue, this will often take over what the would have said otherwise--skewing the results.
So far, we could extrapolate that "Repetition wastes twice as much time as Evaluating 3rd party code" but this isn't an accurate statement. each occurance of "Evaluating 3rd party code" may take three times as long as each occourance of "repetition". A more accurate conclusion is that "Repetition is more likely to be a waste of time".. but it may also be easier to work around.
Because your questions are open-ended there's no way you can know whether some of these are actually related. E.g. Flakey API and Evaluating 3rd party code probably are.
Again, I don't know what you're doing with this data but you do need to be wary of any conclusions you make from it.
What I'm hoping is that I'll get enough information for the next post. I need about 20 replies, so lack of data is a problem at the moment.Check out the narrative capture links earlier if this peeks your interest. In the good old days of this forum I'd have probably collected that much in a few days.
The "me too" aspect is a problem, as that can skew things. That said, resonance is still useful.
2. Documenting stuff on our internal wiki.
3. Getting sign off for rolling out new code. We use a simple svn update which takes about 5 seconds, however our procedures take around 4 hours.
Achieving business objectives without modifying the core of open-source software. I've lost track of the number of times when forced to work with open source software that I've said to myself it would be so easy if… I could modify/add to this line of code in this core file. Waste of time but necessary I guess.
The only code I hate more than my own is everyone else's.
a huge amount of custom classes. Never thought that the integration into hudson could take so much time - but it's running by now with all it's unit testing and deployment glory. But it was nasty i can tell you...