Comments on: Concepts and features – an example http://lostechies.com/jimmybogard/2010/09/30/concepts-and-features-an-example/ Strong opinions, weakly held Thu, 23 May 2013 23:40:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Tim Scott http://lostechies.com/jimmybogard/2010/09/30/concepts-and-features-an-example/#comment-2660 Tim Scott Mon, 04 Oct 2010 04:34:07 +0000 /blogs/jimmy_bogard/archive/2010/09/30/concepts-and-features-an-example.aspx#comment-2660 Great post. It's something I've been thinking about quite a lot lately. I notice you said, "we waited too long to formalize the concept," not "we should have discerned and modeled this concept at the outset." That would be YAGNI and paying a debt that might never come due. My own "concept needs formalization" alarm is getting better tuned with experience, I feel. For me it works best like this. The product owner orders a feature. I notice right off that it's like some existing feature. Okay, let's keep it DRY then. So I fire up Resharper and set to refactor the existing code to support the new feature. When it starts to feel sticky and procedural, the the concept alarm rings. Let's model it. Ah, that feels better. Great post. It’s something I’ve been thinking about quite a lot lately. I notice you said, “we waited too long to formalize the concept,” not “we should have discerned and modeled this concept at the outset.” That would be YAGNI and paying a debt that might never come due.

My own “concept needs formalization” alarm is getting better tuned with experience, I feel. For me it works best like this. The product owner orders a feature. I notice right off that it’s like some existing feature. Okay, let’s keep it DRY then. So I fire up Resharper and set to refactor the existing code to support the new feature. When it starts to feel sticky and procedural, the the concept alarm rings. Let’s model it. Ah, that feels better.

]]> By: Nolan Egly http://lostechies.com/jimmybogard/2010/09/30/concepts-and-features-an-example/#comment-2659 Nolan Egly Thu, 30 Sep 2010 19:19:34 +0000 /blogs/jimmy_bogard/archive/2010/09/30/concepts-and-features-an-example.aspx#comment-2659 This is why it's so important to have a good understanding of the scope of a new application. Unfortunately, that's hard :) It's difficult to balance "analysis paralysis" against "YAGNI - oh wait, yes we DO need that", and even then the client is going to change their mind several times after swearing the requirements are frozen. Design is an iterative process. Past experience with similar systems helps a lot (Jimmy will probably make file processing more explicit in his next EDI system). There are some good general books on architecture out there. I like to read project post mortems to understand what system design challenges other teams have run into and how they solved them, but good ones are hard to find. How else do other readers "search for common concepts to build on"? This is why it’s so important to have a good understanding of the scope of a new application. Unfortunately, that’s hard :)

It’s difficult to balance “analysis paralysis” against “YAGNI – oh wait, yes we DO need that”, and even then the client is going to change their mind several times after swearing the requirements are frozen. Design is an iterative process.

Past experience with similar systems helps a lot (Jimmy will probably make file processing more explicit in his next EDI system). There are some good general books on architecture out there. I like to read project post mortems to understand what system design challenges other teams have run into and how they solved them, but good ones are hard to find.

How else do other readers “search for common concepts to build on”?

]]> By: Ralf Westphal http://lostechies.com/jimmybogard/2010/09/30/concepts-and-features-an-example/#comment-2658 Ralf Westphal Thu, 30 Sep 2010 15:31:23 +0000 /blogs/jimmy_bogard/archive/2010/09/30/concepts-and-features-an-example.aspx#comment-2658 Hm... sounds like DDD would have helped. If you work according to DDD then concept identification is part of understanding requirements, because concepts are part of the Ubiquitous Language. This does not mean you need to implement all concepts, but at least you´re clear early on which concepts there are. And I´d and from personal experience that then architecting a system as consiting of processes (yes, I know, doesn´t sound very OO ;-) but it works nevertheless) does help to translate concepts into code. So whatever you see in an implementation is part of the Ubiquitous Language - and the other way round. -Ralf Hm… sounds like DDD would have helped. If you work according to DDD then concept identification is part of understanding requirements, because concepts are part of the Ubiquitous Language. This does not mean you need to implement all concepts, but at least you´re clear early on which concepts there are.

And I´d and from personal experience that then architecting a system as consiting of processes (yes, I know, doesn´t sound very OO ;-) but it works nevertheless) does help to translate concepts into code. So whatever you see in an implementation is part of the Ubiquitous Language – and the other way round.

-Ralf

]]>