81–90 of 378 posts
You are basically say much of the same as Dan North is saying in his newest take on Agile: https://www.youtube.com/watch?v=iFLBG_bilrg Agile is dead, long live Agile. The difference now, is that we understand trade-offs. There's no silver bullet and there are no absolutes.
Earlier quoted context omitted.
> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer working closely with two teams. One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. I find the non agile team more productive, efficient and dare I say happy. The Agile based team makes me sit in on the…
One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's certainly closer to Agile than to Waterfall, assuming they didn't do a big design up front before writing any code. I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just th…
But of course. If you just cherry-pick and experiment, then you won't have any reason to pay an expensive expert to tell you how to do it right!
I've seen the addition of unit testing is a big cause of complexity. Previously simple classes now have to be more abstracted in order to unit test. Add mocks, testing classes & test frameworks. Some unit tests are handy, but I dont think it justifies the additional complexity. For the apps I write I'd like to see more emphasis on automated integration testing and fewer unit tests - so we can write simple classes aga…
Proper unit testing also complements integration testing in that corner cases can be handled at the unit test level, therefore reducing the amount of integration test code which arguably is much more brittle, runs slower and more complicated to write.
Earlier quoted context omitted.
A "1 hour daily standup" is not agile. The point of a stand-up is just that... everyone can stand because the meeting is so short. Ideally 15 minutes max.
It's annoying when people get really dogmatic about having to stand up in the stand-up meeting. I know it's supposed to remind and encourage everyone to keep the meeting short, but in my experience that simply doesn't work.
Earlier quoted context omitted.
Quite a few of these issues are common in other orgs. "You're doing it wrong" isn't great advice :/
I would say in a lot of cases understanding that there are some basic failures is probably a great starting point to cleaning up the development effort. There's not much else I can say other than that, considering how vague OP's post is. "Good" engineers will get things done and use common tooling to their advantage. This requires actually understanding the principle behind the tools, not just shoving things in and h…
If you want to develop better practices in an industry, saying the practitioner should be "good" isn't very helpful. Of course they should be good! But unfortunately, despite the trope, we can't all hire the best, and part of the reason we have best practices is to work well without only hiring the top 1% of engineers.
An example from my experience (mentioned in another comment)- microservices are a good practice in many larger orgs, because a big piece of what they solve is political- but the overhead of running a distributed system at a small org often isn't worth it.
>> 0, Are we over complicating software development?
Yes, in many cases we are over complicating software development. I think a large part of OOP too complex to produce reliable services easily, still possible though. Simplicity is not as popular among developers as it should be. I often run into complex code that can be replaced by 10x smaller code base that is much clearer than the original.
1, Sure
2, I am not sure why you think that, you need services that can few things well and individually scalable units. This used to be SOA (service oriented architecture), and micro-services lately. There are cloud vendors out there who make it super easy for you to run such services for reasonable price on their platforms without a devops team.
3, See point 0. Complex systems fail more than simple ones. Failure isolation and graceful degradation should be properties at design time. The best is to have stateless (no master slave service or registry that is required for correct operations) clusters where you can scale the capacity with the number of nodes.
4, Continuous integration is way older than the term microservices. It contains patterns that a company figured out by shipping code that had to be reliable and it is optimised for frequent changes aka when you developing a new service or product. It is just a way of giving instant feedback to developers.
5, There are so many talks and videos about agile used bluntly is harmful on the web that I think this is a well understood question. Use a method that works for the team, it provides the insight to the business what they are doing and you are good. I use Kanban for almost 10 years with distributed teams (software and systems engineering) and it works perfectly for us.
+1 for simpler code and simpler software
The rest are debatable, but I feel that the point above is close to an axiom these days.
Earlier quoted context omitted.
> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer working closely with two teams. One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. I find the non agile team more productive, efficient and dare I say happy. The Agile based team makes me sit in on the…
It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.
There is no one true way to organize development of software and generally shoehorning dogma without proof of value is counterproductive.