This is a post I have written and rewritten many times over the last few months, I still find it imperfect and will probably catch many flames for it – but what the hell, “If you’re not creating trouble, you’re not creating much” as Hugh MacLeod says. This blog will attempt to talk about certain developer practices, how it affects Basis/Technical people. I am writing this to start debate so we can explore a more common language and understanding that build a culture supporting philosophies like Lean and #DevOps. Also I fully expect, in fact I demand, that someone write a rebuttal to this post :-).
I have spent the last 9 months immersed in #DevOps stuff, trying to find ways to engage the SAP ecosystem with it and see how SAP, customers and consultants can learn the lessons of #DevOps the same way it learnt and adopted Agile. So as we have seen in previous blogs, #DevOps is built around a concept of
C – Culture
S – Sharing
At first glance these are quite technical and operations oriented things, I was a lot more interested in the Developers and how I as a technical person can help/work with them to create something amazing. My first step was to start to learn to talk their language, something which is like a difference dialect of SAP. Then to make matters even more complex, I also had to learn the language of the Web world as well – something which was a lot harder and by no means complete, I reckon I am talking and reading WebDev stuff at a 5 year old level :-). I have been ably assisted in this journey by a lot of friends, DJ Adams, Ethan Jewett, Steve Rumsby, Matthias Steiner and others (you know who you are)
Many administrators I have come across have no idea about developer practices, they know the rudiments of how developers work in the ABAP stack, but very little about Java, ADS or WebDynpro. I am nearly sure that some administrators, especially those who are not co-located with their developers, think that there are sacrifices made at the full moon to create the code or the code is produced through Ouija boards. So as I have said above this a miss-mash of thoughts to try and kick start closer collaboration and also start to alter some practices to make life easier.
1. I need you to help me speak your language and I need you to learn mine. Especially non-ABAP developers – you know who you are, you have ignored us for long enough, we have let you get away with it and it stops now!
We all spend time working on projects, and our managers make us sit in different areas so we can be with our teams. Is it any wonder we have lost the language of the birds, now I am not talking about being fluent or fully understanding how things are done but as a minimum I think we should have a common understanding.
2. I need to be a part of your change process.
Between us we must be able to agree on how we get code into the Production system. There are people who set down rigid rules, there are people who use 3rd party tools to enforce a process. There are those who just fly by the seat of their pants. Bottom line – there HAS to be a process and we all have to abide by it, live with it. Stop trying to go around it in order to get your ‘little’ fix into production because someone did not test it right! Before the integration of many of the SAP products into CTS+, I wonder how many Basis people actually understood or could support moving changes through the landscape of NWDI, CE and Business Objects. I propose that between developers and Basis people, we begin to understand the following – and yes this is very simple stuff, but if we do not understand the basics, then we cannot build good lean processes.
- What does a change look like in each type of system
- How does that change get migrated through the system
- How do those changes get applied
- How do those changes get tested
- How do we ensure the quality of the changes that enter the process
Someone recently asked me – why do Basis even do transports surely our time could be better spent on other things. Something else to ponder as you discuss the points above together.
3. An extract of the transport history IS NOT a transport build list.
Let me say it again, just in case I have not made myself clear – the next developer who tells me that I should use the Transport history of a system as the release build list, will be punished in the most severe way possible. You and your team are the developers, it is your development – do your job and track your changes, I will help you – I will even provide some tools or tricks which will make life easier. Do not treat me like your mother picking up after you – you are not a rock star and I do not work for you, I want to work with you.
4. Object Management and conflict resolution
If you are working in a BAU environment, please, please, please – release your tasks quickly and often, not your transports (although this would be nice). This ensures that the object locks get released and other people can use the objects. Of course this creates dependencies between transports with overtakes and undertakes. You know what, if we have worked together and have a solid process, we can mitigate that through both tools and processes. I have refereed enough bun fights between developers who need the same object but one has it locked – bored of doing that and I want to do sexy fun work.
5. Integrate your code quickly, the job is not done until the system works.
Often as a Basis guy, I am supporting the development work of multiple vendors – and everyone is doing their own development in their own environments. The nightmare starts when Integration testing starts, I will admit that we in SAP have a major deficiency in testing. We often do not use automated testing, and that is a travesty in it’s own right. So testing is a pain, when dealing with multiple code streams with multiple vendors, it has always appeared to me – that all developers keep their code streams as separate as possible and then at the last second merge them. This has 3 effects
- Development have to scramble like mad to develop fixes, increasing the number of changes
- Transport sequencing becomes ultra important, and someone decides to use the import history as the sequencing method
- The flurry of change can derail the change process as priorities get escalated.
I have been thinking for a long time of two potential ways to improve this situation.
- Everyone can have a development system, but there is a single QAS, Pre-Prod
- A dual track landscape, one BAU and one Project. All code co-exists within the landscape
The bottom line is this – your development job is not done until the code works properly in my Production system. The sooner you get your code integrated with everything else, the sooner it can be tested and reduce the last minute panics. Of course that does assume that all the developers from all the parties play nicely with each other.
6. You are not always getting your own environment
This is an extension of the item above, I do not have limitless hardware or resources. I have to make a judgement call on what resources you get to run your project. This means that you may not get your own environment to work in. That does not mean I hate you, or do not value your project enough – often it means I actually can’t do it, or it means I am not going to stretch my team further in supporting another set of environments so you do not have to be nice to other developers (or so it looks to us)
Work with me, educate me on your requirements – do not try to pull the wool over my eyes and try to get more than you need. Let me help to support you with a brilliant service, rather than stretched to within an inch of my life and providing a crap service to everyone
7. Stop complaining to me that there is no test data in Development
This is an old one, but it is one of the most frustrating for both of us – I know you guys need good data to test with but it is not acceptable to do your unit testing in QAS. I want to help you get decent test data, I know that generating it is a nightmare and often belongs to the functional consultants as a task. Lets stop fighting with each other and gang up on the functional people to get them to actually do their job in supporting us for a change!
8. You manage to turn around code fixes in no time flat
I am always amazed by how developers know their systems and can turn around fixes to problems in no time. In fact if the truth be told, it makes me a little jealous sometimes.
9. You guys have bigger teams than we do
Often on projects or in BAU, developers outnumber the Basis guys – there are times, I am the only Basis guy assigned to a project. You have development colleagues you can bounce ideas off if you get stuck. I like the way you do stick together and support each other – a sweeping generalization I know but it is more often true than false.
From reading above, it looks like I find developers do more things wrong than right – nothing could be further from the truth, but the things above are mostly things that drive me nuts because we could be doing things much better.
I look forward to reading your comments whether they be positive or negative.