Professional development

Who’s Who in the World of Agile?

September 6, 2012 by Adrian Stolarski

In the article The Evolution of a Technical Information Professional Keatron wrote about the development of each of us in information security is impossible to disagree with in that it takes place in this way. But in the case of persons employed in the production of software, to put it mildly the case is different. We want to look at this subject up close and see what it looks like in our case.

Good bad beginnings …

At the beginning of his career, each of us begins with the selection of the path. Will I be a developer or QA or security engineer, we all go through it. At the beginning, we feel very confused. We begin to explore technology we use in everyday life.

Then we begin to struggle with ourselves. What do we really want to do? Do we want to focus on unit tests or functional end user experience or as a programmer, choose the working environment, then use the technology? The important thing is to always move forward and develop.

The natural course of things is that the junior becomes the medium, and the medium becomes the senior. Now let us ask ourselves the question, when does this happen? Do you know of developers who are over 40 years old and still sit and write simple functions in the language of your choice? A very similar thing happens in the case of QA. Do you think that an experienced software quality engineer sits all day writing simple unit tests?

And now the question is how to evaluate the experience of people from the IT industry. Imagine a programmer, who for 10 years did not do anything, and writes only simple scripts in JavaScript. How much experience does he have? A year or ten years? A programmer imagine that in 10 years he met 10 different technologies and has participated in 10 – 20 projects. What is his experience? In my humble opinion, it is easily over 10 years. The same is true of the QA.

Our programmer, a quiet guy who spent his days writing modules

Here, everything begins with a few lines of code. The project manager assigned our developers to start writing simple tasks requiring a few lines of code and dealing with only a few hours of work. Then I start getting more advanced tasks. For starters maybe a small, poorly advanced module, and then more and more powerful units.

Everything is going in the right direction, if a programmer is slowly starting to distinguish different design patterns. But it’s really the beginning of the road. Now he must begin to understand and see many other things. He must know when inheritance is a better option than the use of the interface and that the decorator design pattern is used only as a last resort, because it is a very dangerous decorator design pattern.

The next step is our programmer’s code refactoring and optimization. Let us discuss first the issue of refactoring. Well, sometimes we all have to deal with the type of spaghetti code and must choose whether to wade into this further, or simply do a refactoring of everything we can. Mostly refactoring is useful, but sometimes it is a threat to the project because it is unknown whether in the refactoring everything works as it should. After successfully refactoring several times, I suddenly notice something unusual. We start to get a class consisting of 500 lines of code and methods that contain more than 20 lines of code. Therefore it is passed by the refactor. And what happens? Do others complain about the large number of classes and methods? Of course not. This allows them to make improvements in small pieces of code without affecting the rest of the application critically. Thus we were able to perform a successful refactoring code, and we can go to the next step, optimization.

Hurrah! We will optimize the code, said the team, and they happily threw themselves into the optimization process. And what happened? The algorithms did not perform at all faster, and some were less stable. Here we recognize that we are dealing with an unhealthy way of doing things. But let’s see what really went wrong. The answer should reveal itself. We optimized the program, which really was completely unnecessary. We could instead extract only the most time-consuming memory-code elements, and focus our attention on them. Then surely the optimization process would be successful.

Each developer must go through itand when you go through all these steps, you will reach the end of software engineering. Exceptions to this rule is the infamous industry centered around computer games, which provides the programmer with virtually no possibility of development. After firing the developer, in his place comes a new programmer. Very unwise approach.

At the end I have for you two notes: The first of these is a set of rules that is certainly useful to you:

• Keep It Simple, Stupid

• Keep It Simple and Stupid

• Keep It Small and Simple

• Keep It Simple and Sloppy

• Keep It Short and Simple

• Keep It Simple Sophisticatedly

Here is note number two:

• The greatest sin of developers is creating a software to try to predict what the future holds, rather than spend time and energy on the design of the system, ensuring that it is cheap to maintain and allows you to quickly make changes in the face of new challenges.

• It is worth spending the extra money on a good design so that in the future the cost of maintaining the system is reduced.

• If you are not able to eliminate the complexity, you should cover it with something simpler so that other developers do not have to look there.

• Write only code that you really need and remove the code that you do not need, because the maintenance of a “dead” code costs the same as “working”.

• A good programmer is the one guy who makes the code understandable to other programmers.

• The code does not make money. It’s the people who are making money and our programs are helping them do that, so the overarching goal should always be to help other people achieve their goals.

• The more code there is, the more likely it is that you will have to change it.

• The larger the piece of code you enter into the application, the greater the risk that something goes terribly wrong.

• Comments in the code should say “why” something in the code functions “like” it does. The code should be clear enough that the programmer was able to answer the question “how”. {unsure of meaning, gave it my best -SJ}

• You know your code and how you test it.

Hey DJ, I’m the QA

We wrote some unit tests, we know what is functional testing, we found errors in a program and tested a trial application. At the interview we ask questions like, what do we know about the quality of the software and what topics are of particular interest to us. Everything was done neatly and without much interference. We find, however, we are not the first one dealing with writing unit tests and functions, and, for example, begin to evaluate programs in terms of intuitiveness and functionality for each user or group of users. This principle was used by almost every software quality engineer.

Then we begin to explore other aspects of this highly addictive work. For example, we can start by writing a simple unit test and learn the ideology of writing documentation for testing. We start from the principle Given … When … Then … and write different test scenarios. Then I formed our first self-test and functional test, and finally we are able to develop a tool for fully automated tests. Is this the end of our journey? Definitely not.

It may happen that we specialize in the field of application of the final user experience. But it is also not our main goal.

In fact, our experience as a software tester is to detect all possible errors that can be committed in the phase of preparation of the technical specification and development of software architecture. Quality engineers must also work very hard to push the team to make good coding practices. This allows you to really improve the efficiency of software developers and improve the quality of software. At the end is a thorough analysis of the finished product and the QA decides whether a product can now be presented to the customer.

In fact, work as a software engineer is not the most pleasant. He’s really going on and talking to people about quality processes and the rest of the game. Sometimes it is just for the hundredth time the developer needs to say that this makes mistakes, and the programmer as the programmer, the attack on the code can be seen as an attack on his own person. In addition, the QA is responsible for the initial contact with the client and preparation of technical documentation of the project. In the event that technical documentation and client specifications are of poor quality, then the product is doomed to failure for which QA is blamed.

Once he understands the product, its philosophy, and the brand, very often the QA Project Manager conveys it to the whole team because it was he who best knows the product. AM Best which I know personally, have had QA track. In this way they are able to fully understand the process and all the laws that govern them. They will certainly be better than dev PM who did not pass their path before.

I was a dev or qa and became PM – what can I do?

They promoted me to the PM and what do I do? The task manager is encompassing the project as a whole. A good PM knows his project, and he knows what’s going on and who is currently responsible for the items in the project. In addition to the tasks, the PM connects with customers and the selection strategy, in which the project has to go into Agile.

Oh and one more thing. Every one should know PM corporate culture of your company and should not deny it. In a healthy situation, PM gives its employees a channel to always appeal against a decision.


Briefly discussed in this article are the three main ways in which we can go designing software or working on a production. My approach has taken me through all three tracks, so I’m really dev vocation, and now I’m in a software engineer’s own company, although still a dev working with a company. As a dev I can tell you briefly what I expect. From the project manager I require a logical From the QA I demand unconditional response, or writing something, I follow in the right direction, and rapid response to my mistakes and the understanding of my people, because they do not like any dev who wrote the correct code. I hope you find this articleinteresting.

Posted: September 6, 2012
Adrian Stolarski
View Profile

Adrian Stolarski is a freelance security tech blogger, specializing in Java, PHP, and JQuery. In his own words, he does the hard work of training the unemployed. Currently, he handles Evaluation Visualization for real-time systems with XWT and Eclipse RAP. If he sees that something works, he asks how it works and why it works, then sets out to make it work better. A researcher for InfoSec Institute, he currently lives in Poland, but plans to move to London.