Tag Info

Hot answers tagged

84

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: ...


43

Aim for the head: "Lead by example" should have improvement in mind, but it should be targeted on people not on technology. Maybe you have invested too much time in improving technology, but not enough time in what is going on in their heads. Think about the driving factors why there is an opposition for new things. In many cases they just fear some risk. ...


41

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 ...


30

Have you ever stopped to consider that you might be wrong? So you read some designs and patterns books in school and you are disenfranchised with what seems like comparitively antiquated practices where you work. No doubt they are probably better ideas and new projects should start with these in mind, but it seems like you are on a completely different ...


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 ...


13

Sometimes a change is large enough that you have to design a migration path. Even if the start and end points are well designed, you often can't just switch cold turkey. A lot of otherwise good designers fail to design good migration paths. This is why I think every programmer should do a stint writing software for 24/7 production environments. There's ...


12

In an ideal Agile world, you agree a price up front and a number of hours, but not scope. The customer decides what the minimum useful product is, rather than the product they really want, and that should estimate well short of the number of hours agreed. Then you deliver to them iteratively and they change their minds all they want, but you never go over ...


9

If your team find email disruptive or tune it out, something is wrong (they've set their notifications to be too in-your-face, or they're getting too many private emails, or they haven't set up filters/triggers properly). Email is, in my opinion, the perfect tool for this. Set it up right and it will serve its purpose. You could do something silly and ...


9

I'd recommend you to read the Big Ball of Mud essay. Basically the point that the design tends to deteriorate as you progress with development and you have to dedicate work towards containing the complexity. The complexity itself can't be eliminated, only contained, because it's inherent in the problem you are trying to solve. This leads to the main ...


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 ...


7

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 ...


7

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 ...


6

What you've described doesn't sound like "lead by example" to me, it sounds like you made a proposal and were rejected. To lead by example you need to show people that your way is better. Of the problems you listed I see three that you can start using your own changes yourself. Plain old makefiles which only support full rebuild. Create your own ...


6

You need (preferably automated) integration / system tests too, apart from unit tests, precisely to verify that changes like your example don't break existing - seemingly unrelated - functionality in your system as a whole. UI testing is much more difficult than unit testing, but there are tools which can help at least somewhat. For web pages, e.g. HttpUnit ...


5

In addtion to Lionel Barret (which I mostly agree), consider also the possible motivation to the resistance. Evaluate the cost of the actual process Evaluate the cost of the process as it will be like yours But also: Evaluate the cost of the change in term of Money to spend to setup the new environment for anyone Time to spend to train everyone to be ...


5

By making the case, just like anything else. You start by asking yourself this: What are the problems that our current methodology has, and how would agile help fix those problems? It may not be an easy sale. Going Agile completely requires a different mindset, a different way of doing things, and a different corporate culture. Specifically, the Agile ...


5

The best way to do something like this is to do it in small steps. First, even when you add this group, the students are transitively related to single class. So while there is some kind of grouping on the inside, the outside interface might ignore this and present only Student-Class relationship. So first step might be keeping Student-Class relationship, ...


5

If I may be so bold ;) The problem isn't really about unexpected schema changes to production, though that's certainly a symptom. In reality it is: "Why aren't different members of my organization communicating about changes that affect each other" Once you view it that way then it makes more sense to look at: current processes of code and database ...


4

I think that your #2 is the way to go. Such problems can only be solved by talking to the customer. Tell them that changes are costly - both in time and money. Show them your estimations and indicate where their new changes interfere.


4

In general terms, there's "pieces of code" (functions, methods, objects, whatever) and "interfaces between pieces of code" (APIs, function declarations, whatever; including the behaviour). If a piece of code can be changed without changing the interface that other pieces of code depend on, then the change will be easier (and it doesn't matter if you use OOP ...


4

The author of the blog post was trying to make a point about how the Agile Manifesto emphasizes "working software over comprehensive documentation", and that when you do this, you risk losing the information about how software is supposed to work. What's needed, whether it's Waterfall, Rational Rose, Agile, or some other SDLCM, is a "statement of purpose". ...


4

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 ...


3

Agile and 'Write an offer' seems like an antithesis :) - the latter is not productive software engineering :D Okay, now that we have the joke out of the way - back to the real thing. "How does it work in Agile?" - the contract complicates things but I hope to make it clear. Agile is founded on the prinicple of 'trust' and 'co-working' which means that the ...


3

This is not really related to Agile programming or whatever model you use. Working as a freelancer, I use a mix of Waterfall and V-model, but still have the same problem: what if the customer wants to change something during detailed design? What if he make changes during implementation? The approach you have to use depends on the customer and your ...


3

I don't think you can ever tell just how much a change will affect code. That being said though, if one know the framework of the application well, he can generally predict about how long it will take and what needs to be done. It comes from experience, not metrics. I'm sure you've thought of cases that a user thought a change would be simple ('He's just ...


3

A design pattern's complexity can bite you if the problem it was supposed to solve suddenly disappears. Sadly, due to enthusiasm and popularity of design patterns, this risk is rarely made explicit. Your friend's anecdote helps a lot to show how patterns don't pay off. Jeff Atwood has some choice words about the topic. Document variation points (they are ...


2

I was just about to ask this same question. I think we've all worked for clients/bosses that constantly shift gears. Here's a typical work week for me (at times): Monday: Boss says, "Hey, I came up with this great idea over the weekend! Lets do it!" So I spend the rest of the week coding it up and testing it. Next Monday: I say, "Okay, here's that great ...



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