Analysts versus implementers

[Otávio Macedo]

Has anyone here had the experience of working on a project where there is a distinction between "systems analysts" and "implementers"? Roughly speaking, analysts are supposed to produce UML diagrams, while implementers are expected to translate those diagrams into source code.

Although this idea is such a complete nonsense, some companies insist on enforcing this policy. I am very aware of the fact that the ideal solution is to create an agile environment, with more respect to the quality and readability of code (so we don't need extra documentation) and so on. But, given that some simple-minded managers take this transition as an enormous, even revolutionary leap, what would you, fellow craftsmen, do in a situation like that? Have you ever had to cope with this problem?

Thank you.

--
Otávio A. C. Macedo

http://softwaremetaphysics.blogspot.com

[John Pritchard]

Need to be able to describe the problem that arises.  What is represented in UML and what's the translation to software?  Is the UML exporting structure like design patterns, or is this ambiguous in the engineering process?  What's not expressed by the design, and how is this a software design problem?

There would be many layers of 2D diagramming to capture the dimensions present in software.  Unless the design team is working in terms of this problem, their separation from practice risks being remote.

Ambiguity in the engineering process leads to confusion among team members, moving the need for design work from one place to another.  If the need for design work as been moved into an unknown or unrecognized place, then the team is not supported by the process.

2010/8/22 Otávio Macedo <otavio...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

--
http://www.google.com/profiles/john.douglas.pritchard

[Alex Baranosky]

I'd seek employment elsewhere. Honestly I feel trying to change an
entire culture at a company is a lot more work, and with no guarantee
of success (maybe not even a statistically likely chance of success
even)

Good luck to you,
Alex

>> software_craftsma...@googlegroups.com<software_craftsmanship%2Bunsu...@googlegroups.com>

[Kurt Häusler]

We have a situation where we have "consultants" and "developers". The consultants are more like business analysts rather than systems analysts. The are customer facing, and work with the customer to more fully flesh out the requirements, but depending on the specific situation, also go part of the way into specifying the solution, identifying which database tables may need to change, and which gui windows may need to be extended. In general it seems to help rather than hinder, it means we can simply get going with a story on day one, without having to make appointments and sit in meetings. Sometimes we developers would need to spend so much time researching the background to the requirements, and the existing source code etc that we wouldn't actually get to any coding. They are definitely useful for their domain and product knowledge. It has been suggested that we move them into our scrum teams, as usually the developers have to work closer with these consultants than with other team members, but this hasn't yet been accepted as a good idea because they tend to operate several sprints, or even a release ahead of the developers, and spend a lot of time with the customer site.

Opinion amongst the developers seems to be divided, some seem the current structure as favorable, and see the consultants as bridges to the customers, and sitting in meetings, writing docs, and doing other things so we don't have to, saving our time so we can concentrate on development, others of us, inspired by the idealism of agile values and principles,  seem them more as a wall between us and customers, and wonder if it would be more effective to have the developers working closer to the customer perhaps alongside the consultants, utilizing them for their domain and product knowledge.

But craftsmanship and agility aren't necessarily the same thing. I know McBreen's craftsmanship talks about close relationships between the customer and craftsmanship, but Uncle Bob style clean code craftsmanship seems very coding focussed and I think from this perspective many craftsmen may agree that anything that helps developers spend more time coding, and less time in meetings may be a good thing.

So even though I work in a situation that approaches a "specifications being thrown over the wall" type culture, I favor both the agile value of customer collaboration, as well as the McBreen craftsmanship value of building closer customer relationships, (I see those meetings as where the software is truly developed, when we sit in front of the PC we are merely typing it in) I see the issue as being fairly orthogonal to craftsmanship. It should be possible to learn and grow, and deliver customer value, as cleanly as possible while having pride in our work, whatever the business context we are surrounded by.  If anything I would say less than ideal circumstances provide situations where we are outside our comfort zone, and have to be especially creative to work within constraints, and end up learning even more than when we are well inside our comfort zone, surrounded by ideal circumstances.

I guess once it stops being fun, and the analyst-implementor relationship stops working, and motivation suffers then it can be considered a problem, but  I think in some cases it can be hard to identify specific problems, and could even permit developers to focus better on clean code and craftsmanship.

I suggest any developers unhappy with being in such a situation prove to their managers that it really would be more effective to work directly with the customer, to spend less time coding, and more time in meetings, and still increase at least the quality if not the speed of development, at the very least you may prove yourself wrong, and provide yourself with an opportunity to challenge and refine your values and principles, at best, you will be able to deliver more value while doing so in a way that you feel is right.

[Nicholas Robinson]

I really liked the response Kurt gave; full of gold.  I doubt I can add much.  I did want to share with you that the situation you are experiencing, is in my experience more common than you might think.  There are perfect agile shops, and there are clients all around the world learning and growing through the hard work of the agile agents of change that have taken their own journey towards helping to educate them.  But there are still a lot of traditional places too. I am sure you could leave your place (current econmic client aside), and of course you could stay and become an agile agent of change.

 

The different roles of a software development effort have their roots in traditional ideas of software engineering as a discipline.  Some teams/companies follow the traditional because of what they know and because they have experience and some internalized level of success with it.  Depending on the situation, the skills of the team, the topology of the whole team structure, traditional might seem like the better approach over other neo-disciplines.  That may or may not be true, but its often not black and white.

 

I dont think craftmanship is about just being agile either. I think agile values and principles exude a heigtened appreciation for the discipline, but they do not define the discipline.  And while a coder with thousands of hours of practise will surely be on the unending road to craftmanship and mastery, software craftmanship is much more.  Cory Foy wrote a good piece early this year about focusing on other aspects of craftmanship, from team work to collaboration.  I share this view.  A master woodworker, while a craftsman, does not fully map to software in my opinion.  So just focusing on the code, while rewarding, is limited IMHO.

 

And therefore the answer is in the question - if we are craftsman that have answers to solve this problem you face, it implies that it is more than just coding, being agile or something else more focused.  Your situation requires an agent of change, be it agile or some other approach.  You could walk away, and I dont deride anyone who does that, as I have walked that path once or twice myself.  I would say the problem you face is in how do you become that agent of change, how do you model, imbue and exude the values and principles, practices and disciplines that can lead the minds of your team to a better place? You are not faced with a simple problem, because in truth you need to slowly change the beliefs of others, which is not easy.  But I do believe a craftsman/journeyman harbours the qualities that can help with this problem.

 

I am in a place that is traditionally chaotic, and they have had a lot of success with this approach.  The more success with something, the greater the challenge in changing someones beliefs about that artefact of success.  But almost always, there are little opportunities to model something.  Such opportunities were not apparent when I first got here, and my puer aeternus bubbled underneath the surface.  Eventually I saw some opportunities to demonstrate a different approach to the collaboration required between the customer team and development.  The requirements provided to use by our BA were only half complete.  So I started split the work up for myself into excel, with user stories and then the acceptance tests, which we all call executable specifications now.  I kept this to myself, but referred to it in meetings, dropping in nomenclature when I could.  I even started creating my own burndowns and putting them up above my monitors.  Slowly people asked me what the graphs were, and I showed them my own personal plan. 

 

Dont get me wrong, a personal plan, my own burndowns, my own version of requirements are all heresy in some respects, depending on the motivation for their creation.  I am early in the process of guiding some semblance of change, and all of these artefacts are nothing but nudges towards slowly developing experience with different concepts in the minds of my team members.  Unless a team/company has willingly requested someone to come in and mentor them on a different approach, other devices of change are required.  Patience is a necessary quality for an agent of change.  I have had to let small battles be lost, much to my chagrin at times. 

 

Progress is being made. Slow or fast? These are just concepts.  I let go of a time, and let go of any need for this situation to be fixed immediately.  In only a few months however, we now talk about user stories, scenarios, velocity, test driven development, contiual integration, iterations.  The BA has been the greatest challenge and I would say he is still the anchor in the sea.  I honour his fear of change, and take it upon myself to adapt and develop the appreciation and understanding of him as a person, so that i can work more effectively with and develop trust.  Relationship building has been key.  The quality of work I and the team are putting out now has gone up dramatically, and the ability to make changes is much quicker with little fuss of re-engineering.  But all of these skills that in my opinion do embody craftmanship, do not come even close to the impact relationships and collaboration has had.

 

In the words of Gandhi: Be the change you want to see in the world.

 

Whatever that may look like.

 

Warm regards,

 

Nick.

 

 

2010/8/22 Otávio Macedo <otavio...@gmail.com>

--

[Nicholas Robinson]

This popped up today coincidentally:  http://ht.ly/2tscG

[pif]

Hi
I have worked in this kind of environment.
This is complete nonsense, as you say.
The "analyst" tend to make design decisions instead of the
"implementers",
which leads to sub-optimization.
You *must* organize things so that analyst and implementers work
together,
a kind of "pair design".
Good luck !