How should I behave as a developer in a project that's headed for failure? • Hacker News Board

Re: How should I behave as a developer in a project that's headed for failure?

#161

Post by dsuth » Thu, May 30, 2013, 2:30 AM UTC

ap22213 wrote: post #144

kvnn wrote: post #126

Earlier quoted context omitted.

In this landscape, that can be a lucrative specialty to have. Do you actively market yourself as such? > Sometimes it's better to cut the team down from 5 to maybe 2-3 instead of adding more people Tried and true. > If there isn't one, stand up an automated test harness with as many tests as possible What do you think about adding on another developer to just do testing? What about a full-time QA person, so that you…

I haven't really thought of marketing myself that way, but that is a great idea, Thanks. I guess I've never thought about it because I'd imagined that it'd be such a niche skill that it would be difficult to build a consulting practice around it. People are always looking to build new things. But, they're maybe not as welcoming to talk about their failing projects. Anyway, I have probably (inadvertently) turned aroun…

Hah, as I was reading your post I was thinking "they should hire this guy to fix it up". Triaging projects is definitely a valuable skill, and like any time/mission critical skill, likely to be highly paid if you can market as such.

Re: How should I behave as a developer in a project that's headed for failure?

#162

Post by jasonwocky » Thu, May 30, 2013, 2:36 AM UTC

jdavid wrote: post #87

ap22213 wrote: post #46

I've picked up so many of these types of projects, it's sort of become my specialty. The first thing to do is to ask oneself if it's worth completing the project at all. All stakeholders _will_ have to be ready to make some sacrifices; is it worth it? Also, like others have said, communication is key. If the team can't have open conversations up-front, it may be best to walk. But, if the team can communicate openly a…

As a Developer, I would buy a book or pay for a class on a topic covering how do you improve team dynamics and strive for success. Most of my schooling and knowledge is from the perspective of building a 'thing' and it would be great to learn how to rebuild a team when management is lackluster. Out here in Silicon Valley there are a lot of inexperienced managers working on good or great products, and as an engineer y…

I'd recommend just about anything by Jerry Weinberg, starting with "Becoming a Technical Leader". "How Software is Built" and "Why Software Gets in Trouble" are also great, as are much of the rest of his opus, but I'm one of those folks who really resonates with his perspective.

Re: How should I behave as a developer in a project that's headed for failure?

#163

Post by TerriGriffith » Fri, May 31, 2013, 3:20 PM UTC

PaulHoule wrote: post #117

CodeMage wrote: post #94

Earlier quoted context omitted.

Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a place that lets a project fail as badly as the OP described it. I've been in situations like that too often and I've learned that particular lesson too well. Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointi…

I think that level of "failure" isn't exceptional in the field. It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B". "Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables. "Team B" sometimes delivers the product, usua…

That percentage is about right for all organizational change. The data also suggest that implementation, not bad ideas, is generally to blame. Possible solution: change the situation where you do have the influence. Work across all the dimensions of people, tech, & org process to find how you might make a suggestion that will stick. I gave that advice to 40 folks just yesterday in class (I teach org design & innovation management at Santa Clara Univ).