Comments
Why Your Software Development Process Is Broken
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
moarsauce123
50%
50%
moarsauce123,
User Rank: Ninja
9/14/2013 | 2:31:26 PM
re: Why Your Software Development Process Is Broken
You are missing a few key stakeholders and roles in the software development process:
- business analysts: they compensate the lack of tech knowledge of the product manager and write detailed requirements documents to be consumed by anyone involved with development
- QA: they cover both testing and quality advocacy (the "A" in "QA") and should be talked to and talking to product manager and BA before any developers come into the fold
- customer support: who better than support to tell you what is wrong with your software and what is needed? And who better to make a final call if a new version / product can go out as is without generating a lot of follow up cost?

Lastly, make developers at least handle upper level support cases. In most cases developers will never use the software they make in a production setting. Shielding them from the pain points that the customers encounters cannot lead to anything good. Nothing straightens out a developer more than a complaining customer...after all, developers didn't want to hear what QA, BA, and support told them all along. The biggest fault that can be made is leave all decisions to developers, they know how to write marvelous code, the rest not so much.
rradina
50%
50%
rradina,
User Rank: Ninja
9/13/2013 | 11:50:32 PM
re: Why Your Software Development Process Is Broken
I wholeheartedly agree on that point. IT certainly needs strong leadership to prevent it. However, so too the business needs someone to curtail the relentless amplification of process complexity because it tries to chase every customer "shiny thing" regardless of how distant they wander from the core business.
hyih
50%
50%
hyih,
User Rank: Apprentice
9/13/2013 | 11:00:48 PM
re: Why Your Software Development Process Is Broken
anyone remembers Steve Jobs?
D. Henschen
50%
50%
D. Henschen,
User Rank: Author
9/13/2013 | 7:25:54 PM
re: Why Your Software Development Process Is Broken
This seems like an experienced, in-depth diagnosis from somebody who has been there and back. I'm not a developer, but it seems pretty straightforward that more direct interaction between developers and users would be a good thing: fewer intermediaries = more reliable communication.

But would it not be equally effective to have developers AND product managers sit in on the same requirements-gathering interviews with the customers (even if the PMs aren't technical)? Does the benevolent dictator really have time to oversee decisions by all developers and all PMs?
TerryB
50%
50%
TerryB,
User Rank: Ninja
9/13/2013 | 5:04:24 PM
re: Why Your Software Development Process Is Broken
Seems to me you will still have a problem as old as software itself: Which customer do you listen to? Customer A says "got to have this, essential to use". Customer B says "I don't need that, just makes things more complicated.".
So you take a poll and 56% of customers agree with Customer A and the rest with Customer B. Is it as simple as going with majority? That may not get those customers to contribute any more revenue. But it may irritate the other 44% to look elsewhere, costing you revenue.
Is that world developers, or even benevolent dictators, need to live in? Seems like where Sales & Marketing earns their keep to me. Somehow they have to work together.
jemison288
50%
50%
jemison288,
User Rank: Ninja
9/13/2013 | 4:49:39 PM
re: Why Your Software Development Process Is Broken
I'm not arguing that developers only develop things without ROI; I'm arguing that developers--left unchecked--will often choose to develop things in a way that often uses unideal technology solutions (either using too many new/different/cool technologies or using same-old, same-old technology without thinking about what is available out there).
rradina
50%
50%
rradina,
User Rank: Ninja
9/13/2013 | 4:29:02 PM
re: Why Your Software Development Process Is Broken
I disagree that only developers invent features with no ROI. There's plenty on the business side who fire up the waaaambulance because they don't want to prove the viability of a new business model with a small-scale manual procedures before requesting millions of IT software enhancements. Then when the business model doesn't work, IT is left with a new dimension of complexity and tons of dead code. Rinse and repeat and is it any wonder why custom software is riddled with dead code and no-longer-used features that are continually maintained each time they fail an automated test case?

Example: A former employer hired someone from a similar LOB who arrived with thunderous ideas. After getting chummy with the CEO on a business trip that demonstrated the success of these ideas elsewhere, the CEO immediately ordered IT to support these new ideas in several pilot locations. Despite IT's plea for an small-scale manual tests to prove and refine the process with limited IT support, we spent six months feverishly adding features to support what was billed as something that was going to not only attract new customers looking for these new uber-convenient services but it would also more than pay for itself and allow for additional investments in price to beat competitors on loss leaders. (Queue applause sign)

Not only was the pilot a failure but there was the belief that if we give it enough time, it has to eventually work. (Sound familiar Microsoft?) More locations were added which only exacerbated the complete failure it already was. It was finally killed after the new services became the target of con artists who made an already costly mistake even that much more of a dead end.

Without a doubt the complexities added to the organization's software still exist and continue to plague their software maintenance staff.

Granted, sometimes new business models are only a success when combined with technological automation. However, I've seen quite a few crazy ideas that wreck IT portolio plans because some new hot shot upper management type joins the company with big but unproven ideas.
<<   <   Page 2 / 2


Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 14, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.