April 8, 2016 at 10:47 am
Comments posted to this topic are about the item Hunting in Packs
Best wishes,
Phil Factor
April 8, 2016 at 11:33 am
Hi, Phil, I believe the scenario you're referring to can best be summarized as CXPACKET blocking for teams.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 9, 2016 at 2:00 am
Excellent post about a problem which was appearing when I had to stop to work ( around 2000 ). More time to define the structure of an application than to write it with , too often , the ignorance of the future of this application and its maintenance. But maybe , there is another problem : how long time is needed to change all the persons working about it ? Maybe a problem of money , too often , companies prefer to see their staff leaving than to increase their wages ( at least in France where we say often "one lost , two ones found" ).
I have during more 25 years worked nearly alone or inside small groups ( 3 up to 10 people ) which were near of the end-users , it is easier to understand the problems and the wishes of everybody. Moreover , I am feeling that the way to teach the computer science is done by people who have not worked in the real word but maybe it is the aim of this post...
Sorry for this long reply maybe confusing because my difficulties with the English ( and American ) language(s). I am using English one only on forums.
April 9, 2016 at 3:21 am
Good post. Every good practice can become a bad practice if taken to extremes. Sometimes it takes an outsider to point out what is going wrong.
If you are looking for more similar thoughts, then I recommend "77 Sure-Fire ways to Kill a Software Project". It's dated, but I read my copy from time to time to remind myself of the mistakes I've made in the past. 😉
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
April 9, 2016 at 1:21 pm
On one WinForms project that I remember there was a very long process that made the app appear dead. We got complaints. The developer added a progress bar and a timer. Every time the timer ticked it would increment the progress bar. When the bar got full it would reset and start over. It onlylooked like it was making progress but had nada to do with the actual task.
What I find to be very destructive is Scope Creep. We actually started calling one sales manager the Scope Creep. Every time this Creep came back from a client meeting the Scope grew but the timelines did not adjust. It got so bad that we only had time for "happy path" testing.
ATBCharles Kincaid
April 9, 2016 at 2:49 pm
Very true.
Many developers of the past 10 years appear to be obsessed by TDD,Scrum,Agile,dependency injection,Entity Framework and yet do not understand databases - "there be dragons!!!!" I wouldn't work anywhere these mantras are in place.
A few years ago around 2010 the company i worked for a company developed an n-tier SQL database driven web app with a web ui, business object tier and data tier plus many stored pprocedures. It was a pattern I and colleagues of mature years had used for over 15 years when Rocky Lhotka appeared on the IT horizon. It was highly maintainable and extendable into the future and was effectively almost an MVC type of architecture.
Then the company wanted to outsource a new develipment/version to a London based "software house" called....and I kid you not...."Geeks"
So Geeks asked for the code and we gave them that and the stored procedured and database extract. After about a week and subsequently meeting theiir team, it became apparent they just did not understand stored procedures and why we would use them.
The company quickly decided the retain development in house and rebuild it with MVC ,C# ,Telerik and keep the SQL server database architecture.
N. McCreight
April 11, 2016 at 2:34 am
Eric M Russell (4/8/2016)
Hi, Phil, I believe the scenario you're referring to can best be summarized as CXPACKET blocking for teams.
Nice description!
Slightly sad for us technical types when analogy to technology is more obvious / comfortable than talking about human relationships but there you go 😉
April 11, 2016 at 5:38 am
Could just be the fact they lacked any real coordination or vision, not that they are all working on the same problem. You didn't, that's why you solved your problem so fast.
You really can't make an argument that splitting up a single problem into multiple pieces, where each worker is assigned to solve that piece of the problem as a slower process unless you have the wrong people tasked with solving a specific piece of the problem.
For example, how distributed processing works. You take 1,000 sheets to be graded in a class and divide 1,000 by 10 students to help you grade them. Now each student is grading 100 sheets of paper at the same time as opposed to one teacher grading 1,000 sheets of paper by themselves.
People are too quick to blame the methodology than rather how they executed the methodology as the problem. Sure, you can sit there and say that hunting in packs is the problem. But, I could take the same approach and likely solve complex problems with it because of the difference in execution.
I think in most instances, lack of execution or lack of vision is to blame. Not having the right teacher to identify and lead the students is going to cause much more damage than the methodology.
April 11, 2016 at 7:18 am
xsevensinzx (4/11/2016)
Could just be the fact they lacked any real coordination or vision, not that they are all working on the same problem. You didn't, that's why you solved your problem so fast.You really can't make an argument that splitting up a single problem into multiple pieces, where each worker is assigned to solve that piece of the problem as a slower process unless you have the wrong people tasked with solving a specific piece of the problem.
For example, how distributed processing works. You take 1,000 sheets to be graded in a class and divide 1,000 by 10 students to help you grade them. Now each student is grading 100 sheets of paper at the same time as opposed to one teacher grading 1,000 sheets of paper by themselves.
People are too quick to blame the methodology than rather how they executed the methodology as the problem. Sure, you can sit there and say that hunting in packs is the problem. But, I could take the same approach and likely solve complex problems with it because of the difference in execution.
I think in most instances, lack of execution or lack of vision is to blame. Not having the right teacher to identify and lead the students is going to cause much more damage than the methodology.
I have appreciated this sentence "I think in most instances, lack of execution or lack of vision is to blame."
I have heard an error from a product manager also during the transfer of data from SQL Server 2000 database to a new SQL Server 2008 one ( with replacement of TEXT columns thru NVARCHAR ones thru a VC# application ) : he estimated that a test with 5% of the records was enough to determine the new necessary space and the elapsed time during the transfer. It could only give a minimum duration ...
April 11, 2016 at 7:34 am
I agree that leadership is important. In the case I wrote about, they each thought that they were individually responsible for particular work items. In a sense they were but they all felt the need to get a lot of help from the rest of the team in order to do it. That meant that they 'hunted in a pack' but with a different pack leader for each work item according to who 'owned' the work item. That meant that they worked serially in a pack rather than working in parallel. I don't think that this has much to do with the methodology. I've seen the same thing happening in a whole range of methodologies. Any project manager or team leader should be able to spot when cooperative working degenerates into hunting in packs, and take whatever action is necessary. Even wolves only hunt in packs once the quarry is on the run, before then they work singly, within a team.
Best wishes,
Phil Factor
April 11, 2016 at 9:37 am
"Hunting in Packs" is the wrong metaphor.
If you have ever seen wild dogs hunt, (Planet Earth series has a great scene), it's not the mess described with this group of programmers. The programmers exhibit more of a "flocking" behavior.
Of course most of "agile" is "cargo cult"...
April 11, 2016 at 10:14 am
This is how IT management sees it. 😛
'Cat Herders'
https://www.youtube.com/watch?v=m_MaJDK3VNE&feature=player_detailpage
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 13, 2016 at 12:54 am
basic requirements for coordinating teams and ensuring that they are working cooperatively
The above from the editorial sums up for me that management is key. Often many of us complain about the problems caused by project management but, for once, I would like to highlight that there can be problems caused by the absence of project management.
I suppose that it can be boiled down to that there are many issues likely to occur when there is the absence of good project management.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 21, 2016 at 6:23 am
I think "hunting in packs" is a misnomer for what the editorial describes. I'm not sure what it should be called. It seems to me that the management must be encouraging people not to assume responsability for their own components - how else could a team of reasonably competent people get themselves into this sort of mess?
And yes, that would be one of the worst things that can happen to a project when it's in a stage where working on independant chunks is needed. But everyone working on everything is actually a good thing in the early stages of a project, first while people are trying to understand the requirements and reach a position where those requirements are stable enough to be meanigful, and the second while the team is trying to determine an overall architecture for the product and an overall methodology for implementing it, so that it becomes possible to assign bits to subteams and/or to individuals and get out of the everybody on everything mode while giving each team member a decent overview of the whole thing and of how his work is to fit into the overall objectives. Maybe weak management can start out with everyone being involved in everything and then forget that this only works in the initial phase of the project so that the project is perpetually in early design mode and never reaches implementation or prototyping mode, but I think it's more likely that the project would be slowed down a lot but still get into prototyping, implementation, testing, validation, and release than just go nowhere.
Other disasters can be nearly as bad. The waterfall methodology often leads to disastrous overruns (both in time and in cost) and only slightly less often to total failure on large-scale projects because it has a management concept that imagines everything about timescales, costs, and implementation tools can be determined in advance before any design study or technical evaluation of how the requirements should be met has been done. So I don't think "hunting in packs", even at the wrong stage of the project, is actually any worse than using the waterfall methodology for anything other than very small, effectively trivial, projects.
And a plethora of newly hyped old ideas contributes a lot to software development failure: the misunderstanding of things like "extreme programming", "agile", and other rather ancient development methods (with shiny new overhyped names) and their consequent misuse does a lot of damage.
Tom
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply