1. The manifesto for agile development has turn into a sort of religion and through all my experience and from what I've seen Jim Coplien, David Thomas, Robert Martin, etc. are saying, it seems pretty clear to me that us people from the IT industry have no clue what we are doing, and are constantly reinterpreting and clarifying the basis of our professional activity, in a time where we should have everything set and well-oiled.... I mean it is 2021 and we are still discussing the fundamentals... How on Earth is a house supposed to stand if the foundation is brittle ? We need to take a cue from other, more established industries, we need to use the right set of practices for the right set of people and in the right context. Not every project is the same, in terms of complexity AND budget. Budget is something that is highly overlooked in this talk about agile software development. Managers, especially CFO's are very attentive to the money problem, because if you keep taking money from a bag, without thinking about the consequences after that bag is empty then you don't have determinism in project, it's just putting money in a black box and waiting to see what comes out of it, maybe it is something useful, maybe it is something half-baked, and usually it is the latter. If you make a simple website, and you have the experience, then it is easy to estimate that a project will be done in 1-2 weeks and that it takes ..idk $1000, but if it is a distributed system that does some heavy number crunching on one side and some fancy UX/UI on another side, then you need to consider prototyping, feasibility, system design, onboarding experts and onboarding juniors or less-experienced people that can learn from those experts, you need to allow for learning, experimenting. Agile development and scrum has been turned into a mean of milking the developers dry, of their energy and ability. Agile and scrum has become a tool for managers to force rapid development for BUDGET reasons. It all ties down to budget, every company wants to get a BANG for their bucks, and it usually involves agile development with the software developer at the end of the food chain .... It is especially interesting when the project leader decides a specific deadline without consulting the technical team on the feasibility of that deadline.
2. Taking the idea of the budget from point #1, and eliminating it, and combining the lack of budget with open source software, you can see that the quality of the software can be pretty high, and the libraries and interfaces that these libraries expose, plus the user guide offered alongside these are of high quality and high completeness, especially because the software developers that put time and thinking into these libraries and tools have the time and are not constrained by the budget and the deadline. So I agree with Jim here on the weird economics of software development.
3. Making your own tools can be interesting, especially when developing highly customised products that have features that are very different from what framework A or B has to offer, and it would be absolute murder to try to beat with a hammer a TV screen hoping it will turn into a guitar... and there's plenty of examples where something like this happened, like turning a Wordpress setup into a customised e-commerce website with very specific wizard like panel flows that are not covered by the actual e-commerce plugin, having to hack that thing out to smithereens, fiddling with the core code of the wordpress framework and the e-commerce plugin, which is absolutely painful and counter-intuitive. If you want something specific, very different from what a plugin or a framework has to offer then you would better start thinking of how to write it from scratch. If however you don't have the budget of doing that and you are fine with using the features of framework A or B, or plugin A or B, then that's the only thing you can do and ...so be it.
4. Related to #3, I do not however agree with an idea that every time ...
1 comment
[ 2.8 ms ] story [ 12.2 ms ] thread2. Taking the idea of the budget from point #1, and eliminating it, and combining the lack of budget with open source software, you can see that the quality of the software can be pretty high, and the libraries and interfaces that these libraries expose, plus the user guide offered alongside these are of high quality and high completeness, especially because the software developers that put time and thinking into these libraries and tools have the time and are not constrained by the budget and the deadline. So I agree with Jim here on the weird economics of software development.
3. Making your own tools can be interesting, especially when developing highly customised products that have features that are very different from what framework A or B has to offer, and it would be absolute murder to try to beat with a hammer a TV screen hoping it will turn into a guitar... and there's plenty of examples where something like this happened, like turning a Wordpress setup into a customised e-commerce website with very specific wizard like panel flows that are not covered by the actual e-commerce plugin, having to hack that thing out to smithereens, fiddling with the core code of the wordpress framework and the e-commerce plugin, which is absolutely painful and counter-intuitive. If you want something specific, very different from what a plugin or a framework has to offer then you would better start thinking of how to write it from scratch. If however you don't have the budget of doing that and you are fine with using the features of framework A or B, or plugin A or B, then that's the only thing you can do and ...so be it.
4. Related to #3, I do not however agree with an idea that every time ...