Timeline for Is there a programming paradigm that promotes making dependencies extremely obvious to other programmers?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2017 at 14:57 | comment | added | Christs_Chin | @BernhardHiller it seems you're suggesting that Software Engineering is a difficult subject...too true! Unfortunately education is only possible for people who see value in the learning opportunity and the team i'm in don't value maintainability and readability at all. They're all incredibly smart and capable, but their methodology isn't this way inclined. Brad Thomas was correct in pointing out the build first and quick mentality. It's inevitable with with some companies' business model and mindset. It's basically I.T as fast food. Quick and cheap but terrible in the long run. | |
| Jan 18, 2017 at 11:27 | comment | added | Bernhard Hiller | Exactly my experience: you must get your team members understand what they are doing. I see people mixing MVVM and MVC, others using WPF controls in a way which was normal with Windows Forms (or rather: VB6), people programming in C# without a basic understanding of object-orientation... Teach them. Teach them again. Be frustrated. Teach them again, ... Often thinking of giving up. And teaching them again... | |
| Jan 17, 2017 at 16:11 | comment | added | Robbie Dee | @RobertHarvey To a degree but large teams come at a well documented cost. See diseconomies of scale, magical number 7, the mythical man month etc etc. | |
| Jan 17, 2017 at 16:07 | comment | added | Bradley Thomas | @RobbieDee The implementors are still doing a lot of technical design - and much of that is last minute, even on huge, expensive projects, in my experience. | |
| Jan 17, 2017 at 16:04 | comment | added | Robert Harvey | @RobbieDee: If it's a multi-billion pound development effort, you have the benefit of an army of people to help you with all of the little details. | |
| Jan 17, 2017 at 16:03 | comment | added | Robbie Dee | "Software engineering as a discipline suffers from build it first and design it-as-we-go mentality" - wow, just WOW! I could see how in a web development/mobile app development shop that could be the case where you can roll out patches for your various transgressions farily quickly, but I can assure you than in a proper engineering environment, nothing could be further from the truth. On multi-billion pound projects we plan to deploy once and if we can't it becomes hugely expensive - fast! | |
| Jan 17, 2017 at 15:58 | comment | added | Bradley Thomas | @Christs_Chin I think the problem is soluble. I just view it as another manifestation of the problems of short termism in coding, arising from the causes of technical debt. The solution therefore is to put in place the known solutions to technical debt. Having more competent people is a VERY big part of that. | |
| Jan 17, 2017 at 15:44 | comment | added | Christs_Chin | Brad, thanks for the answer. Your response is appreciated as I know I'm not alone in being aware of this problem. It just seems like this in my team. I also agree with Robert Harvey, in that this problem is widespread and I don't want to give up on the belief that there is a solution, either in a new type of software or a new working practise. | |
| Jan 17, 2017 at 15:43 | comment | added | Robert Harvey | Alright, I'll post my own answer as a comparison. I don't think it has anything to do with software patterns. | |
| Jan 17, 2017 at 15:41 | comment | added | Bradley Thomas | I agree there are technical aspects, but I think those are relatively minor compared to the emphasis on a stronger methodology for planning change. I don't see this as being about design patterns as much as a cultural shift towards more planning and analysis, earlier planning and analysis and better planning and analysis. | |
| Jan 17, 2017 at 15:39 | history | edited | Bradley Thomas | CC BY-SA 3.0 | added 298 characters in body |
| Jan 17, 2017 at 15:37 | comment | added | Robert Harvey | I hear what you're saying, but your answer is ultimately unsatisfying, and frankly a bit insulting. It's a larger problem than just hiring better people; even in the small shop I work in, we struggle with this, and I think it's more than just a people problem; I think it has some specific technical pain points. | |
| Jan 17, 2017 at 15:25 | history | answered | Bradley Thomas | CC BY-SA 3.0 |