Sorry for late response, I've been out on the farm for a week.
On 19.05.17 07:22, Piers Rowan via luv-main wrote:
I am seeking advice about cross platform IDE's
that work well with shared
tasks. Ideally something that can import messages from GMail as tasks would
be great (I see another plugin that does this in Eclipse).
It doesn't have to be Eclipse but the main aim is to manage individual
coding tasks better. If we can get some metrics from a management point of
view that would be great. If a platform can support multiple IDE's
efficiently then great.
In my 30 years of managing software development teams, we used products
like "Microsoft Project" for task management. First, I architected the
system, then the team iteratively refined that to generate a "Work
breakdown Structure" in which a leaf task might have a tree address of
e.g. 17.23.42. Then we estimated the time to implement each leaf task, and
let the project management software give us a fright on the total. I
always added 30% to the team's estimates, as we are always optimists.
After linking task dependencies, and inputting available resources to
the project management software, I'd end up with a nifty Gantt chart,
with the critical path clearly identified.
After letting management choose whether they'd let me hire additional
contractors, or just endure the development lead time, I started
development by handing out initial tasks - granting only 90% of the time
allowed. That accumulated a 10% additional reserve to hand out when
gremlins surfaced. (That was rare. We developed embedded systems, and I
kept the designs pretty darn clean. The developers were very good, with
years of experience.)
The "Work Authority" for each task included task requirements,
especially relevant specification clauses, and any resources which might
Given that it can be that the first half of development takes 90% of the
time, and the second half of development takes 90% of the time, I never
asked a developer "What is your current progress, i.e. % complete?",
instead asking "How much more time do you need to finish?". Now,
instead of tracking % of allocated time consumed, until 90%, then
jamming there for an indefinite period, the answer provided prediction
of task overrun before it had happened.
Using that system over the last two decades, I never had a project run
over time or budget. (Given the liquidated damages contract clauses we
sometimes faced, the former often wasn't an allowed option.)
As for cobbling up some sort of "burgers & fries" ticketing system to
hang off the developers' IDE, how do you handle the dependencies? How do
you show delivery slip five months before it happens? (So you can fix it
while it's still possible.)
At the two companies, a German and a Japanese global corporate, we just
went with "Unix is the IDE". Vim & exuberant ctags, cvs, and I forget
the name of the bugtracker, were more than sufficient to efficiently and
effectively wrangle projects of up to 8 man-years in C & assembler.
(And across various targets, including 68k, PowerPC, V850, AVR, we used
the GNU toolchain pretty much exclusively over the last 15 years.)
We were helped by a documented and audited development process - a
vital part of the quality system. If either internal or external
customers wanted a requirements change after the document had been signed
off, I stopped development, we analysed the change request, and reported
the additional development cost and the delivery slippage. Then they
decided whether they really hadn't known what they were doing when the
original requirements were defined.
That worked splendidly at the German firm, but I remember a meeting in
Dallas, where the American marketing chap wanted to change around 30% of
the requirements a couple of months before delivery. We didn't see eye
to eye on that one.
To me the above is just recounting what worked best on million dollar
projects, but it might be perceived as a rant, since it doesn't fit the
modern Point-n-Grunt rat-wranglers interface idiom, where font & colour
are considerations, it seems. In conclusion, I'll suggest that it's less
important what an engineer uses for a hammer, than how he whacks with
"Walking on water and developing software from a specification are easy
if both are frozen." - Edward V. Berard