Tag Info

Hot answers tagged

71

I see some wrong assumptions in this question: code with design patterns, though applied correctly, needs more time to be implemented than code without those patterns. Design patterns are no end in itself, they should serve you, not vice versa. If a design pattern does not make the code easier to implement, or at least better evolvable (that means: ...


37

My humble opinion is that you shouldn't avoid or not-avoid using design patterns. Design patterns are simply well known and trusted solutions to general problems, that were given names. They aren't different in a technical manner than any other solution or design you can think of. I think the root of the problem might be that your friend thinks in terms of ...


14

In your example of using the Null Object pattern, I believe it eventually failed because it met the programmer's needs and not the customer's needs. The customer needed to display the price in a form appropriate to the context. The programmer needed to simplify some of the display code. So, when a design pattern doesn't meet the requirements, do we say that ...


12

Would this be considered as bad, cowboy coding, anti-pattern. Short answer: no. Doing "agile" correctly does not mean "no planning", it does mean not to overanalyse things. one of the major reasons why Agile is used is because clients often change the requirements. That's an oversimplifying statement. "Changing requirements" is also about how the ...


9

Then we first need to refactor many of things because the real needs are a little bit different You are creating a false dilemma. Real needs are almost always different than what users think/can tell you. Agile attempts to find these differences closer to when the code is written instead of at the end of a full project. Agile is NOT "we will just ...


9

It would appear the mistake was more to remove the pattern objects, than to use them. In the initial design, the Null Object appears to have provided a solution to a problem. This may not have been the best solution. Being the only person working on a project gives you a chance to experience the whole development process. The big disadvantage is not ...


8

The title question, where innovation refers to smaller-scale creative advancements in a team that is already doing well in Agile. The best answer is summarized in this article about "Gold Card Days". Summary (paraphrased, and with my own interpretations which may not reflect the author's intentions): Developers can identify interesting (intellectually ...


7

If you don't test a User Story (US) and verify that the acceptance criteria are met this story is not done. If its not done this US goes to the next sprint of course. And if all your US are in this state you sprint has ended with no value added to the project. From the client point of view I cannot distinguish this from the entire development team going on ...


6

Back to Agile Manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Nothing in these values forbid innovation. Actually, innovation has a better nest with Agile than with Waterfall. Nevertheless, it ...


6

I don't think it does. Agile is about eating chocolate elephants - taking a large task and breaking it down into manageable chunks that can not only be delivered, but are delivered regularly. Research type projects do not fit into this - not unless your project can be broken down into small chunks that can be demonstrated every fortnight (or longer - ...


6

The question seems to be wrong at so many points. But the blatant ones are: For the Null Object Pattern you mentioned, after the requirements changed, you change a bit of the code. That's fine but it doesn't mean you 'murder' the Null Object Pattern (btw, be careful with your wording, this sounds too extreme, some people too paranoiac won't see this as ...


5

Using agile in this situation is still a very good idea. There are many benefits to agile, only one of which is regular feedback from the customer and the ability to respond to changing requirements as you mention. One of the main reason waterfall projects are notorious for failure is the 'nearly done' problem - testing produced piles of bugs at the end, ...


5

One possibility: If you are concerned about loss of productivity by rotating a team member, your manager has the correct approach, and will most likely be seriously concerned (if he's any good), but not saying so. As companies grow, they become less concerned about immediate productivity and more concerned about continuity and predictability. Issues such ...


5

Let's pause for a moment and look at the fundamental issue here - Architecting a system where the architecture model is too coupled to low-level features in the system, causing the architecture to break frequently in the development process. I think we have to remember that the use of architecture and design patterns related to it have to be laid on a ...


4

I think that there is a common misconception as to what BDD means, that BDD means that we are now writing our tests using tools like Cucumber, SpecFlow, etc instead of traditional unit tests. That is not the case. BDD is more a way of thinking that moves our focus in the tests from the technical aspects to the more business oriented aspects. Also see this ...


4

"New developer leaves the company - wow we wasted a whole bunch of time." There are a classical response to this: why if you don't invest time in the training of this developer and he decides to stay at the company? In my opinion is a good idea that developers rotate between teams, normally this gives developers a better understanding of the company as a ...


3

Define "planning" By "planning" I think you mean understanding the needs and figuring out how to do it, generally with a group of stakeholders (esp. users) and developers (et al). This involves a lot of conversations, thought, learning-time, etc. Traditional methods try to plan too much to start, almost always with incomplete/unstable information. Agile ...


3

If the user of your software is not able to update to the new version and use it without further manual migration steps (data, configuration, interfaces and the like), that is a strong indicator to increase the major version.


3

I think some of the challenge starts with your assertion of: Where a Major version is implemented whenever there are breaking changes And I'm pretty sure you mean "breaking changes" in the sense of significant API changes; client / server communication changes; protocol work, etc. "Big Stuff" (TM) in other words. But the problem is that it's not ...


3

New developer will bring down the work rate of at least one experienced person as they constantly ask questions. This is a good thing, in moderation. Every process has countless sources of friction - be it tooling-related, design-related, or whatever. Trouble is, a lot of your sources of friction you don't notice. Having someone come on board brings a ...


3

if all or most of the coding is not done until the end of the sprint? Why is it not finishing sooner? This key limitation is the source of your troubles, and I've seen two approaches be successful. One fits well into the agile approach (but not other common practices) and the other taints agile a bit (but is more common). The first is that you don't ...


3

The actual role of your QA is close to acceptance testing. I would imagine this to be done by a separate team, which acts more as product owner rather than a part of the development team. Example: during a sprint, you need to add a feature which enables to filter search results by different criteria. You already have your search mechanism implemented, but ...


3

Although agile is based on a minimum viable product and only delivering what you need, it is also based on making the best decisions you can with the information you currently have. This means not only considering the user story you are working on, but what you know is coming, or likely to come. The correct time for design is whenever you need it - ...


3

Part of this is expected and good, part of this is not, and we can't really tell you which is which. The main focus of agile is delivering what is important now, based on what you know today. Take a little bit of time, implement this important bit and ship it so that you can get feedback on it sooner rather than later. Some of that feedback will be "ugh, ...


3

Your friend seems to be facing numerous headwinds based on his anecdote. That is unfortunate, and can be a very hard environment to work in. Despite the difficulty, he was on the correct path of using patterns to make his life easier, and it is a shame that he left that path. The spaghetti code is the ultimate result. Since there are two different problem ...


2

The essential problem is that you have programmers who code but don't test and testers who test but not code. Solve that problem and you will not have this problem, and an arguably more efficient team. One way that worked for me in the past was to suggest coders and testers to pair on stories with the explicit task of delivering a fully tested story. ...


2

We've addressed this by adopting the Kanban approach. We have queues in our tracking software (Jira) with minimum and maximums. We groom 'as needed'. Might be once a week, might be 3 times, depends on the limits and the work that get done. This will help you in getting the product owner focused on keeping your queue with plenty to do and can reduce ...


2

Agile is ideal if you need a frequent feedback loop with the client. This can be because the requirements change frequently, but it could also be for other reasons. On the other hand, Agile can work equally well if the requirements are fully stable and the client expects only a single big-bang delivery, but you might have to adapt things a bit for the ...


2

Agile doesn't mean no planning, or even less planning; but it can mean no planning phase in the project. In a true Agile project, the team is always planning, but in smaller chunks. Every new piece of knowledge gained nudges 'the plan' in one way or another. The plan itself is fluid and accepting of change. The problem is that there is a tendency to want ...


2

Ideally you want the product owner to be the person who signs off on the final product. They should be either the client you're selling the product to, or, if that's not possible, the final person who is selling the product to the customer. The idea is that this person knows what the final product should be and can guide it's development from afar by ranking ...



Only top voted, non community-wiki answers of a minimum length are eligible