DISQUS

Hei, Rolf

Jeg er enig med deg i at noen av påstandene i artikkelen min kan virke som stråmenn. Men jeg har fortsatt til gode å få noen til å komme med en konkret påstand om "hvorfor SOA" som jeg kan forstå som noe annet enn en av disse fire.

Din holdning til at det hele dreier seg om forenklet infrastruktur virker pragmatisk. Betyr dette at du grunnleggende sett sier at "SOA = SOAP + en del andre passende teknologier"?

Dette er det mange SOA-evangelister som er uenige i.

Jeg er selv uenig i at SOAP + venner har tilbudt en pragmatisk teknologistack. Jeg ønsker ikke å "hoppe bukk" over disse standardene, men i stedet stanse før dem: Ved HTTP og XML.

Thanks to Marcus and Espen for valuable experiences of trying this kind of approach.

I think the most valuable point is that being dogmatic either way (like the original article) is a bad thing. Like Thomas says: "There are no 'best practices', only good ones".

But I find Espen's comment about not having enough information to create the structure in an agile project to be puzzling. I find I can organize user stories in rough features. Isn't this sufficient?

Does anyone else have experience on finding feature categories for your code?

Thanks for the comments.

I suggested this structure for a project some time back, but a few others insisted that it was "too weird". John O'Hanly has made a web framework called Web4j that he claims uses this structure. It might have some more clues.

Domain classes that are used in multiple features: Most examples I think of the classes have one main feature. For example, "product" would probably be used by "order", but belongs in product. Do you have an example of a domain class that would be hard to place?

Hi, Eivind

Thanks for another insightful comment. As you say: We shouldn't stop doing object-orientation. My experience is that I should only stop recommending that others choose object-oriented solutions when asked for my input.

Trying to force people to use object-orientation (or testing for that matter) without proper understanding is probably not a good idea. With teaching tests, at least I know what to point to as good examples that won't lead people astray. With OO... not so much.

Hei, Lars Arne

Takk for gode kommentarer.

Jeg tror vi er enige om at det er en utfordring å skulle bygge "systemer av systemer", slik du beskriver. Jeg tror imidlertid at dette er en arkitekturmessig innfallsvinkel som ofte er feil.

For det første er ikke gevinstene av gjenbruk så store som folk forventer. For det andre er kostnaden ved å bygge distribuerte systemer mye høyere enn folk forventer.

Men dette har jeg tenkt å skrive mer om i fremtiden. :-)

Når det gjelder "å få integrasjon ut av applikasjonen" er dette også noe som må gjøres med forsiktighet. Jeg har sett mange middleware løsninger som får integrasjonen ut av løsningen, men på den bekostningen at man i stedet må foreta en kostbar integrasjon med middlewareplattformen. Ooops!

I don't think of the layered system that I'm talking about as a silo. Rather, I think of it as a business level service composed of several component services. What characterizes such system is a great deal of fragmented responsibility.

The people responsible for a single layer generally seem to consider themselves service providers for the layers above.

This is not a agile way of creating software. But it's a common implementation of medium-grained SOA services.

Thanks for the kind words, Eivind. Your closing remark is exactly what I wanted to express.

Hi, Jerome

More great insights!

We have also automated our testing and release process and this helps a lot. But sometimes we run in to minor or major snags along the way. For example: We can have failed to stabilize the code after a bug was discovered in a late automated test. Or maven-release-plugin can act up.

And our PO doesn't want to meet all that often. Or at least that has been what we thought. We do suffer from unfocused iterations, though, and your point of one-week iterations been more focused could apply to us as well.

The main point of my 10 % of business case is that the first delivery of a system often is at the 50 % or higher point. At this point, there's little opportunity to exercise control. Indeed, many of the people I talk to still pursue projects with a delivery date a year or more into the future with a single release. I have had some luck with waking people up when I talk about 10 % of business case, as the rationale for this is so obvious from the goal itself.

As you point out: The first release is the hardest.

But if we could release even more frequent with the certainty of good enough quality that the customer wants, that would be even better.

Hi, Jerome

Thanks for the comment.

You are indeed right that my context is greenfield projects or at least projects that have a long projected cost before any revenue. A more constant revenue flow can possibly be much more aggressive.

My experience is that even projects with frequent iterations often fail to actually deliver those releases. If you don't experience the same, I'm very happy for you. :-)

My project currently demos and simulates production once every two weeks, but we notice that larger projects often need more time to come together, so the "once per month" goal is a tolerant one.

I've added AgileInAction to my blog roll. Very interesting post (although I am not sure I see the immediate relevance).

Hei, Magne

Ettersom "vi smidige" ofte er veldig dypt nede i enkeltprosjekter er det definitivt en kjempefare for å overgeneralisere.

Det praktiske motstykket til det du sier er at vi observerer "dette ser ut til å fungere for oss, jeg vet ikke om det vil fungere for dere". Jeg bestreber meg veldig på å presisere på at jeg har veldig få datapunkter, men det er lett å la seg rive med.

Takk for en spennende diskusjon.

Hei, Magne

Jeg har merket selv at det er veldig lett å falle i felle med å forsøke å avvise kritikk ("deflect") i stedet for å svare på den. Jeg forsøker selv å ta meg i nakkeskinnet mer her.

Forstår jeg deg riktig når du sier at et studie for å finne ut av effekten av smidige metoder (eller feedback) burde hatt en dimensjon til? Slik at spørsmålet blir "innen hvilke problemtype er hvilken iterasjonslengde korrelert med vellykkede prosjekter?"

Jeg skjønner poenget ditt med begge spørsmålene som du spurte på Geilo til å være at noen problemer går det ikke an å ha meningsfull fremdrift innenfor en tidsperiode som er for kort. Er det riktig? For å bruke en utslitt metafor: Det er ikke meningsfullt å ha iterasjonslengde på under 9 måneder på leveranse av spedbarn.

Min erfaring er at de fleste oppgavene innen utvikling kan og bør stykkes opp i oppgaver på under et dagsverk. Når jeg ikke gjør det selv, produserer jeg dårligere resultater (og jeg finner alltid i etterkant at det var en måte jeg kunne stykket det opp bedre). Og det er en ganske stor gruppe med selv-erklærte "dyktige" utviklere som ikke klarer å stabilisere koden sin i løpet av en dag.

Kanskje et annet område som kunne være verdt å få bedre empiri på.

Som du påpeker er det motsetning mellom feedbackfrekvens og størrelse på chunks. Jeg tror den viktigste faktoren her ikke er problemtype, men prosjektstørrelse. Men smidige prosjekter oppfordrer typisk til mindre prosjekter. Jeg tror dette både er for å underbygge hyppig feedback, men også fordi det er en vanlig oppfatning at store prosjekter er mindre vellykket. Som igjen går tilbake til det du sier om planer som er vanskelige å sammenstille.

Et spørsmål til sist: Jeg forstår deg til å si at det er bedre å forske på "NÅR fungerer X bedre enn Y", heller enn "FUNGERER X bedre enn Y". Det kan jeg si meg enig i. Men dette endrer ikke problemet du påpeker med at vi ikke klarer å definere "BEDRE", ikke sant?

If everyone (including the questionable professionals who currently don't really test!) ran continuous testing in their IDE, I wouldn't feel the need to run these tests in CI. But we use our CI server also to build the software and push it out to test servers for performance testing. So I don't know what the point of disabling the tests would be. :-)

I think functional tests will tend to vary a lot from project to project. It really depends on what your interface to the outside world is.

A minute to start up Hibernate (Spring is seldom to blame) is unacceptable for a functional test. In my functional tests, I have replaced the whole persistence layer with a stupid in-memory replacement.

Hi, Geir

Thanks for a very interesting question. I think I might want to expand this into a full entry eventually.

I think the risk of my tests running this quickly are fairly slim. But if it did happen, I would still want to separate out the functional tests that we create in cooperation with domain experts and the system level tests that simulate realistic operating conditions. I'm happy with the system level tests we have now, which stress the system. There's no way these could run in under 1 second.

But neither of these types tests are JUnit tests. Our functional tests are implemented in FitNesse and our system tests are scripts that push data on the system (for a web based system, I would consider JMeter).

For tests implemented with JUnit, I would not see any usefulness in the distinction if things ran sufficiently fast. I might consider deleting tests that were covered sufficiently by the functional tests, but since these are run by different tools, it might be hard to find out exactly what tests could be deleted.

I would keep my CI server, though, so I was sure that changes by every member of the team (myself included!) actually passed the test suite. I might even add a failure condition if the tests ran for too long, to make sure that we didn't start down the slippery slope of slow tests.

Flow is definitively an important component of happiness.

"If all my tests took less than a second"? Do you mean more than a second?

Most of the tests I write first are independent of infrastructure, which means that they run really fast. I try to separate out my slow-running tests (e.g. test that a search generates SQL that retrieves the correct result from the database). I haven't doing any soft of formal categorization here, though.

I find that either I run a single test in the IDE. Then it should run fast. Or I run all my tests for the command line. Then everything should be run. So I don't need to categorize stuff now.

Both Geir and Lars Arne seems to have more insight into the use of ESBs than me.

Personally, I have never seem the problem that Geir is describing with using OO in an event driven world. Granted, I have never perceived this to be a major source of problems, but I end up translating events (usually incoming documents) to "command objects" which update the state of the object model. I've never missed an ESB when doing this. What am I misunderstanding?

Lars Arne's "galvanic divider" is closer to things I have encountered. But in my cases the "galvanic divider" became just another layer of crud on top of many more layers of crud. As I understand it, this view of ESBs would either mean that you have to have a generic representation of any message type or you need to have individual representations for different messages. If you go for the first option, you're screwed, as most people who've tried know. If you go for the second option, don't you just add another layer of complexity with no corresponding value, as the new representation will have to match the old one, anyway?

Maybe it would be clearer to me if I saw the ESB tool you guys use.

Hi, Geir

Do you mean ESBs or BPM? I thought BPM was what people used to deal with events?

Personally, I've never found a conflict between object orientation and event driven applications. I would love to hear a bit of elaboration on this.

Geir Hedemark points out another thing that I didn't really think of about BPM: If you expose and reuse your services (Use Case steps, remember?), you can no longer change these. So your "flexible" processes may be composed of "frozen" steps.

HI, Sean

The program is a command line program, double clicking will produce exactly the message you see. Please execute the command on the command. If you don't know how to do this, you can try out Daniel's description in these comments.

Hi, Patrick

I expect that Dell has a different driver for the XPS 720. As I don't have access to an XPS 720 it is not possible for me to fix this. If you're familiar with C code, you can twiddle around the indices in the buffer and see what happens. If you can find out how to work it, I'll include your modifications in my source code (if we can make a version that works with both the laptop and desktop).

Also, you could look into the Dell official Light FX program, which is roughly equivalent to mine. See http://www.dell.com/html/global/xps/lightfx/ind...

Regarding color choice - this is sadly not possible. My program exposes the full range supported by the XPS laptop at least.

Hei, Nils-Helge

Using plain old Fit is indeed an option that I considered, too. But now I am actually glad I didn't. I hope you'll like to try out the code from this article.

FitNesse is definitely not designed with embedding and extending in mind. But when I was willing to dive into it, I found it wasn't that bad. I really wish my "trick" with writing my own main class was closer to the intended use, though.

Hi, Ole Morten

Three reasons why I don't like solutions like the fitnesse-pom-widget:

1. You have to install fitnesse yourself. PLUS: You have to micky around with the installation. For me, maven is my only installer
2. You have to start up stuff with special commands and stuff. For me, Eclipse is my only application runner.
3. You still have to specify a path to the pom that will vary from workstation to workstation in your tests. For me, there is no changes when you relocate the workspace.

Close, but no cigar.

The debugger is nice, but the result of running the test won't be displayed in your web browser, right?

Hi, Space Monkey.

We either discontinued or replaced all features not included in a web server. Briefly: EJBs we stopped using (thank god for that!); for connection pooling we first used the pool that came with Oracle, and then switched to c3p0; for failover and loadbalancing, we use our expensive switches which already has this build in; for transaction monitoring, we use Spring; we also rolled our own message service implementation (much simpler than JMS, but a drop-in replacement for our use).

This is a pretty common question, and an important one. Sadly, the answer is pretty boring. Which leads me to think that there's a lot of stuff in an application server that we really neither need nor want.

Thanks for your question.

Hi, Keik

I don't get the same error, and I'm wondering if you might've made a mistake in copying the code. The error message is something you get if you say

def method(@param) ...

Or

do |@param| ...

or

{ |@param| ...

Is it possible that you have an extra "(" after "find_article"?

Hi Suezanne.

Yes, you're right. I've corrected the article. Thanks for the catch.

Hi, Aase

Thanks for your comment. I see that you've probably worked on a few happier proposals than me. It always feels like the times I've worked on offers, it has spiralled into a fear-driven hole of documentation. 90 % of what paperwork I've helped create could easily have been thrown away without hurting the final proposal. It's mostly bull* anyway. I'm happy to hear that your experience is different.

I agree that your initial velocity cannot be applied blindly to create estimates, but it's provides a better foundation than any other estimation process I've seen practiced. At any rate, my hope is to move from the mindset of estimates to that of forecasts.

My goal is to open the door and estabilish a dialogue with the customer. In my experience, no real conversation starts when nothing is developed. The paperwork only creates good breeding ground for veiled misunderstandings.

Hi, Jim

Thanks for the positive feedback. I see no reason that XPS M1210 could be controlled the same way. You probably need the QuickSet tool from Dell (http://support.dell.com/support/downloads/downl...). This lets you control the lights directly, and it also installs the drivers needed for my program.

There is actually a WinAmp plugin for XPS lights that does what you want: http://www.winamp.com/plugins/details/146182. Sadly, there is not source code available for it.