They don’t know what they want!

Developing software can be frustrating. In a recent discussion with a junior developer she said, that it’s not easy to develop software. In long hours of hard work the result is built as previously discussed and it works. But the customer says, that’s good, but not exactly what we need.

I remember that feeling, It’s disappointing. Short before the deadline the customer want’s something different. Often huge changes to the codebase are necessary to meet the new requirements. The codebase you were so proud of before starts to rot and more and more bugs sneak into the code.

Why haven’t they said upfront what they really want?

Maybe they said what want but you didn’t understand it well enough. Or maybe they just learned what they really need after seeing your product the first time. Many problems are so complex, that’s not easy to plan and communicate everything upfront. And also, life goes on – markets and requirements change.

Your cannot change the facts above. As hard as you try and the more you plan upfront, you’ll need more time for a solution and it will have the same problems.

Try to start small and involve your customers as early as possible. Try to provide value as soon as possible. Start with a small subset of all the features that the customer wants. Show him the result, and in many cases they are happy to have an incomplete solution early than waiting a long time to get a (maybe) complete one.

This way, by involving your customer, you’ll get early feedback. Early changes are easier and cheaper. You’ll also discuss the details of the feature that should be developed next and the customer can re-prioritise continuously. There will by features the customer said “we’ll need this later, I’m sure”, but then skipped over and over again – or dropped.

The customer want’s working software, as soon as possible. It’s our job to deliver it. This requires planning, effective communication and high-quality (tested) code. Design for change, but build only what’s necessary.

You don’t have to use scrum to be agile, learn about the agile principles & patterns. Change your perspective on the current development process.

Have a look at the “Principles of the agile manifesto“.

“Agile” software development is not the solution for all your problems. But the insights you’ll gain will lead you to a better process. Don’t be the slave of a process, use a continuously reviewed process as a tool.


Are you a developer or do you just write code?

I am now about 10 years as self taught developer in business, and over the last years I learned the one thing: A good developer must know much more then just how write code!

When you just start out, the technology and the code itself are the most important thing. Learning a programming language and really master it by understanding complex concepts is really hard.
As a beginner, you know the frustration of compiler errors, crashing applications and weird problems of all kind. So often you stood before a mountain of problems and after some time and many tries – you will reach the top of the mountain. You jump up from your chair dancing and shouting Yes! Yes! finally! I got it!
This is a rewarding and motivates you to go on. In the best case you continue reading technical books and try to learn another language. You go on and solve more and more and more complex problems and projects. You hack the hell out of your editor and work long, long hours – you’re on the way to become an intermediate programmer. Some developers stop here. They don’t learn new things – only if they have to, and some even can’t program a fizz buzz game without google.

No matter of what kind you are, something strange happens with your projects – over and over again: A shiny new project begins on a green field with blue sky. As the development continues it start’s to rain and the ground becomes a bit muddy – no problem. Things just slow down a bit.
But then, yeah, then comes the day. The day of the meeting with the customer when you demonstrate the application and he says ok – this is good, but not that, what we exactly need! We would like things to go better this way, and by the way we also need this, and that… and you start to become stressed and angry. Why have they changed their mind? A few weeks and month ago we agreed on doing things as we’ve implemented them? Life goes on, requirements (and the business) change.
The time is running up and the way I developed the application, it will become extremely complicated to change it the meet the new requirements…
Time’s ticking and you start to hack around. The muddy field has become a stormy desert with lava rivers. You just want to survive.  After long days, nights and maybe weekends you feel burned out and are just happy that the project is over. Every requested additional feature is blocked “because changes are too complex” or “too dangerous”. Ongoing bugfixes and happy hours in the debugger are normal.

And again, some developers just accept this as the way it is. It’s always been like this in software development – so what. But others, especially those who continue to read and learn may become sceptical. This can’t be the way how software is developed!

So you’ll learn how to test the code. This is again a very, very hard thing. It sound’s simple, but testing your software and in best case adopting test driven development is hard, really hard. To test your code you have to make it testable. You are forced to learn how you decouple classes and how to apply the SOLID principles. Writing good test’s that don’t act like a house of cards and getting a feeling of how to test what – and what not – requires experience which you’ll gain only be doing it over and over again.

Also at some point you may stumble over agile software development. When you’ll try to adopt it, you’ll see that software development is not just about us – the developers. The agile way of development is absolutely different then the way you’ve done it before. Maybe you started with none or some conception or weeks / months of requirement capturing and planning.
As an agile developer the development lifecycle becomes faster. You strive to get working, high quality software to your customer. Good code quality and a safety net of test’s allow you to add features, that the customer wants in a steady pace. You’ll see the debugger only occasionally and yes, there are bugs, but much less. You automate what’s possible and build short feedback loops (Continuous Integration: Improving Software Quality and Reducing Risk (Martin Fowler Signature Books)
and Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Addison-Wesley Signature)).

When you work agile another thing is also changing: You talk much more often with your project team, the stakeholder and / or the customer. Instead of reading large specification documents you learn what and why to implement something by talking with the customer. You have to learn to be come an effective communicator.

And also you’ll notice that you need to organise your work. Different types of work like business projects, internal projects, operational change and unplanned work. Phone-Calls, Mails, IM’s and other distractions all over the day.  Learn to manage your time, energy and the work. I personally use the Pomodoro Technique and Kanban.

Another thing you have to learn about is yourself: How your brain works and how you learn effectively. Andy Hunt wrote a great book about it: Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)

Our business is changing so fast, that everybody who don’t do this on a frequent base is falling behind and is risking to become totally outdated.
Don’t stick only to your everyday business, read and learn also about other languages and technologies.

A professional developer is curious and always learning. He is used to uncertainty and fear and comes over it by breaking tasks into small pieces just starts working in them. He makes changes also in very small steps. He knows about procrastination and about the imposter syndrome. He is aware, that clean and tested code is extremely important, because it makes software maintainable. And maintainability is in my opinion the most important aspect, more important then performance.

Those are some of the things, that I would say to myself if I could travel back in time. That would have made many things easier…. because this is not possible I’ll have to continue to learn from my failures. I want to stay a passionate developer!

Stop Multitasking!

A day in Life of a Software Developer
09:00: Check E-Mails, answer some of them, flag some as unread or important.
09:30: Start Working on Project A
09:45: E-Mail from Colleague,  interrupt Work immediately interrupt working to read it & answer it.
09:55: Working on Project A
10:10: A Colleague comes to your Desk and has a question
10:20: Back to Project A…
10:40: Phone Rings, another Colleague has a Questing to another Project
10:45: Back to Project A…
11:00: Meeting
12:30: Lunch

Do you know Days when you get Home after several Hours of work and ask yourself what you really have archived? Or you feel guilty because you have the feeling that you should have get more done that day? Laying in Bed, thinking about your next days Tasks?

What’s the Problem with Distractions, and Multitasking?
Software Development is a quite complex Task that requires Focus. It takes some Time to get into the Project Environment and to really understand what the Task or the Problem is. Maybe you know Situations where you were think hard about a Problem, and then BANG the phone rings and the bubble over your head bursted. After a 2 Minute call you try to remember of what you thought before and it takes a lot of time to get back into it.

Even if multitasking let’s us feel good – our Brain isn’t very good at it. Usually Multitasking takes more Time to get things done then doing one after another!

If you focus on one Task you can use your full Brain-Power to get into it and to get it done. When you really focus on a Task you feel how you get in a Zone where you work productively and make progress.

Every time when a Distraction occurs your Brain has to switch Focus. This costs Power and takes time. Over the Day you feel more and more exhausted and focussing on a Tasks gets harder.

The big Task Mountain
Do you know this Situation: You are assigned to a big and complex Task, you start working on it but again and again you drift off the another Task that seems more important?

In this Situations our Brain tends to Procrastinate:

If we decompose a big Task into smaller ones it becomes much easier to get an Overview and to get started. You can set smaller goals, see faster results and often the Task doesn’t seem to be as complex anymore.

Kanban to the Rescue

(c() Jeff.lasovski
(c) Jeff.lasovski

As we’ve seen – Multitasking may not be as efficient as we think. Much Work in progress (WiP) forces you also to switch Context more often, but how to Manage all those smaller Task’s?

Kanban is a Part of Lean Software Development. Kanban is a tool to reduce Work in Progress and to visualise you Workflow.

Here’s an Article of Kanban in action:

Kanban is simple to understand and all you need are Post-It’s, a Whiteboard or Online-Tools like Jira Agile or KanbanFlow.

Tomato, help me focussing
Focus is the key to efficiency – but how can I get focussed? Try this: Disable your Mail & Phone notifications, select a Task to Work on and set a Timer for 25 Minutes. After 5 Minutes you start your next 25 Iteration. After you completed 4x 25 Minutes Blocks take a longer break. Sounds crazy? Maybe, but the Pomodoro technique works.

You can track how many Pomodoro’s you complete per day / week and measure how much of focussed work you’ve done. Don’t worry if you have 5 or less Pomodoro’s / day at the beginning. It takes some discipline to resist all the Things with that your brain will come up to prevent you from focussing like checking you Mobile, Facebook, WhatsApp or whatever. But when you get trough this you will see soon results on how much more Stuff get’s done!

Try yourself how many Pomodoro you can complete per day / week without felling to exhausted. It seems like our brain is like a muscle – if it’s overused it will end up in a hangover.

But hey, i don’t have an office – I get interrupted all the time by my colleagues!? Talk to your colleagues and explain them how they help theirselves be reducing the distractions. Ask your colleagues to send E-Mails instead and check regularly for important Task. You don’t have to read & answers all you Mails immediately, often it’s more effectively to batch E-Mail reading / answering. Respond only to urgent Mails immediately.
Your colleagues will be exited about how much more value you can deliver!

Smaller Tasks, Kanban and the Pomodoro technique are just 3 of multiple tools & techniques that help me to get stuff done more effectively and to keep work & life balanced. I use, because it’s simple to use an has  a builtin Pomodoro Timer.

I would love to hear which tools & techniques you use to work effectively and focussed!

This Article @SAP Community Network

Type less – SE80 Editor Code Templates

The “new” Editor has a few nice features that make it a bit less painful to use. I use them to prevent unnecessary typing of repetitively used Code-Blocks and to generate local Classes (Test, Exception and so on).

You can find a Collection of my Templates in a GitHub Repository. Over the time I’ll add further, so if you are interested, you may watch that Repository.

SE80 Code TemplateI you like to contribute please feel free to send a pull request!

Here’s the Repository:

This article @SAP Community Network.