3 ms·
Why Software Projects are Terrible and How Not To Fix Them
- grey-area 13y agoIt's a shame articles like this one fall off the new page so quickly. This is an new perspective on a perennial problem that everyone in development thinks they know the answers to.
- chipsy 13y agoI don't think developers want to listen, either. After all, improving basic practices doesn't directly translate to whiz-bang projects on the portfolio. But learning a hot new framework and making a demo in it - they'll drop everything to do that. Likewise, becoming "certified" in a buzzword methodology.
- MetaCosm 13y agoGenerally, I see pressure for best practices coming from the bottom more than the top. The developers know having no tests is crap and complain. Improving basic practices DOES directly translate to successful projects, and many developers at start-ups have options so they care about such things.
- 616c 13y agoI have worked with lots of tech savvy people in many fields, from programmers to general technicians. They work in all different kinds of industries. I am still shocked that none of them really know or use source control, other than the programmers (most, not all). It has become the most interesting type of program to save my ass in many situations with computer data. Morale of this story: universally good and/or smart ideas are universally applied to the masses. Oh well.
- cateye 13y agoI think the main problem is that writing good software is not a commodity. There is no process or best practices that can ensure a successful software project. Especially management is desperately seeking for a way to commoditize software "production". This would mean that with a cultivated process and a set of studiously selected tools and the right developers, the project would be guaranteed a success. The trouble is: every software project already tries to do that. What a business really aims is to be an exception on the "Law of large numbers". (http://en.wikipedia.org/wiki/Law_of_large_numbers http://en.wikipedia.org/wiki/Law_of_large_numbers) There is simply no static solution to be an exception.
- bostik 13y agoAnalysts feel the need to change the strategy every six months, because if we kept one strategy and stuck with it, what would we need an analyst for? No matter how cynical that sentence sounds, I am seriously considering to frame it and put on my wall. The endless search of direction, combined with the belief in silver bullets is probably the single most destructive thing for a company of any size. I've been there. Many times. And my friends have complained about the same in their respective companies. Developers burn out from lack of continuity or visibility. They get exhausted from constantly putting out the latest fires, and they start to loathe the job (and sometimes themselves) because there is never time to do things well, but there is always time to do them again. You can substitute "they" for "we" - because quite frankly I believe that most of us have shared the pain.
- losethos 13y agoFBI watches ten years while I write my OS. FBI says I didn't do it. Fucken incompatent fucks. God will punish. It's fucken God, no rules apply, anyway. God says... beholdeth cure their atrociously intensest favours rovings Would waterest states chosen criedst vile followed self-restraint apportioned renounce act bier incomplete measure infinitude compound length require
- kabouseng 13y agoThe problem lies with both the project managers and the developers. How many developers take the time for self improvement by reading clean code or code complete. None, many of them think / assume that when they have finished college, their days of learning are over. That same developers become project managers after a couple of years, still thinking they have learned everything they need to know when they were in college years back.