Design Strategies/Philosophies

Elston15 · 8 Feb 2011 at 22:35

At uni, much to my dismay, we have spent ages going over UML and OCL and model driven development and very little time devoted to Agile development (XP, Scrum etc..). My some what limited experience in commercial environments and friends in industry, all seem to suggest that Agile develepment is favoured heavily, most seem to say that SCRUM is becoming more and more popular.

So the Question is, Does OCL and UML get used a lot (or at all) in the real world or is it something that rarely exists outside academic circles?

Dj_Jestar · 9 Feb 2011 at 09:27

I've never used UML, and everyone I've worked with hate it. We use rudimentary diagrams on whiteboards in discusssions to share ideas, but that is as far as it goes. We favour test driven and emergent design over upfront design, but must point out that this isn't always appropriate.

Scrum is huge at the moment, still not as popular as waterfall (i.e. The old fashioned way) but on the up.

gord · 9 Feb 2011 at 09:50

Dj_Jestar said:
I've never used UML, and everyone I've worked with hate it. We use rudimentary diagrams on whiteboards in discusssions to share ideas, but that is as far as it goes. We favour test driven and emergent design over upfront design, but must point out that this isn't always appropriate.

Scrum is huge at the moment, still not as popular as waterfall (i.e. The old fashioned way) but on the up.

The thing is your diagrams are probably reminiscent of UML? I know the other day I was drawing a diagram and without really thinking about it, it was a use case. UML gets a bad rap because of the amount of documentation it creates, but it's elements are commonly used: unintentionally.

It's good to know and will help you so don't shun it. I just consider iterative development to be the daddy.

Dj_Jestar · 9 Feb 2011 at 11:44

Possibly, but we end up with a shape and a line to another shape(s). Can't be arsed with crows feet and all the rest.

The whiteboard then gets ditched/cleaned, and we crack on with TDD. We purposefully ditch the design.

We also, in the more complex areas, will go ahead with the code for a fixed timebox (usually 4 hours), then have a retro to discuss, then ditch everything and start again. This works fantastically.

Jammin1984 · 9 Feb 2011 at 13:53

I dont think ive wrote UML since graduating, but it is good to know for reading other peoples on web or in books. Its powerful and expressive in what its trying to represent.

We are a Agile / Iterative / TDD / CI and DDD. For mid sized web / mobile teams who arent producing shrink wrapped wares I feel it works very well.

On a kinda or related note, if you havent started covering design patterns at uni then get on it. They too are very powerfull. Id recommend Head First over the de-facto Gang Of Four but that might be because im a bit thick

Dj_Jestar said:
We also, in the more complex areas, will go ahead with the code for a fixed timebox (usually 4 hours), then have a retro to discuss, then ditch everything and start again. This works fantastically.

Agreed. On the coal face works very well.

NickK · 9 Feb 2011 at 15:56

I still use UML usecases for exploring requirements. Often people will quote requirements that they think about - leaving large numbers of requirements implied ("oh yes, and that too") to make the system useable.

Sequence diagrams are good for message flows between systems. However in terms of classes etc, a good high level design to ensure the concept is understood (this will change and evolve overtime).

Agile does not mean forget documentation and hack at the keyboard. It's how the work is structured from a management standpoint. The fun is that the majority of product business and commercial aspects are build on committing to delivering functionality on a roadmap - that roadmap fits into the commercial business case which is used to go to the board and ask for cash.

The number of boards that actually will sign off budget to a theme without understanding exactly what the ROI is from the resulting sales revenue is rather low.

Dj_Jestar · 9 Feb 2011 at 15:58

Agile is about iterative development, where by you have very short feedback cycles and thus much higher interaction with your customer.

So yes, Agile is exactly about dropping documentation in favour of interacting directly with the customer on a frequent and regular basis.

Elston15 · 10 Feb 2011 at 22:23

Thanks for the replies, I think learning UML is a good thing as, even if only the concept stays with me it will me worthwhile if only for whiteboard planning. Its learning OCL that I think is totally redundant, I just don't see the point of learning a formal pseudocode other than a few very specific cases where it could be useful.

But on the positive side, had a lecture on XP today and have been told this term we are to be marked on the team's Agile Performance as well as our final product. So now I just have to convince the rest of the team that you have to write tests BEFORE you write some code.

Jammin1984 · 10 Feb 2011 at 23:58

Elston15 said:
So now I just have to convince the rest of the team that you have to write tests BEFORE you write some code.

This took me a long time to get my head around. To realise that unit or integration testing is not for finding bugs but more testing things architecturally. Doing something on layer X should do something on layer Y, and how that

a)Makes what your trying to achive very verbose to another developer looking at your code
b)Lets you refactor without having to know every class inside out
c)Introduces professionalism into your code, think first, test red, green, refactor. Think before you do.
d)Reduces developer testing time massively and lets you be confident that your code under test will work first time.

For me the biggest hurdle was to stopping seeing tests as something to test for bugs but something to force you into writing loosley coupled and maintainable quality code and thinking things though first. Its very much a cliche but the first time you do what you think is a simple refactor that breaks a load of tests youll never look back. I learned a lot from a good friend of mine who is good developer, but that eureka moment only came through doing.

And, things like Selunium push this even further.

The downside is projects where testing takes up 90% of the effort and the production code is an after thought. You will have projects with not enough testing and some with far too many!

Also, **** property injection, favor constructor injection with an IoC where ever possible - factories on top of factories are the devils work. As a friend with more smarts then ill ever have pointed out to me, constructor injection is like documentation; you know exactly what an instance of a class needs.

Dj_Jestar · 11 Feb 2011 at 11:07

In steps BDD and "tests" become "specifications". That subtle change makes a whole lot of difference. Test is something you do after the fact, specify is something you do before - that's how most people will see it. To us hardened TDDers we never test after, always before

TDD/BDD is much more than just writing tests/specs before implementation though. It's about using those tests to drive the next step of implementation. You write one test, watch it fail how you expect it to, then implement the behaviour to make that test pass, refactor the implementation (using the now passing test as proof it was a rafactoring and not a refuctoring), then identify the next interesting test (i.e. what is the next relevant failure) and repeat the cycle.

NickK · 11 Feb 2011 at 19:38

Well I'd like you to try a large project without design.

Agile, is just about working on the highest priority. No that doesn't mean follow the waterfall documentation avalanche but it does mean that there's a design in terms of components etc. If you have 64 people on a project.. you will need a design..

We had over 13,000 unit tests and over 1,300 system (ie start the system up, test and check) that ran every night. Hygiene is key and having the time to refactor is paramount. Often it's better to run a high level component design, just as a reference point rather than having people leave and then having to spend a month reading code yet again to work out how to change things..

Tests have become:
a) a specification of the requirements - checking that the requirement is fullfilled,
b) then as Jammin has said, the tests then check that the code adheres to the design.
c) finally you get to the point where the cost of testing is too high or can be implied elsewhere with an acceptable degree of risk.

Agile works IF your customer knows what they want. This works if your customer is a business analyst for example that has already gone through the company and dealt with the lies, the politics and the responsibilities for the different parts of the system.

Don't get me wrong - I'm working with a developer now who is agile focused. However when the business has fixed price projects to deliver improvements in the company, if the engineer went directly to parts of the organisation.. then you'd not get anywhere due to politics (yes I'm currently doing the business analyst/solution architect/development manager role so I'm the customer).

Software companies seem to be very cerebral in running with the work rather than getting all political and backstabby.. that's the engineer's love of getting something beautiful built rather than climbing to the top of the mound of corpses.

Sorry I've had a grand day dealing with ****.