A Foo walks into a Bar...

A couple of weeks ago I began to develop a new component of the system we ship. In order to not get lost in where I currently am, I decided to employ a tool to visualize structure of the component, and to track progress of its development.

However, I was too busy to write a program on my own. Therefore, I decided to purchase an enterprise solution. I analyzed the market, and asked a couple of questions. And I found a product. The product. "Penn&Paper™'s Progress Tracker 8.3 Personal Edition by Penn&Paper™'s Solutions. The one that suited me, fulfilled all my requirements, and was very easy to use.

I was so satisfied with this product, that I even decided to publish an interview with one of "Penn&Paper™'s" sales managers in my extremely popular blog. To make it more interesting, I accompanied it with pictures about my experience with usage of their product.

Interview with a Penn&Paper's Solutions™ representative

So, here it is. Violet Page, a sales manager from "Penn&Paper™'s Solutions" presents their "Progress Tracker 8.3 Personal"!

Pavel Shved: Violet, first, I must confess that I'm a fan of your company nowadays. You seem to create very "natural" products for human beings to operate. So, I guess, that a description of how easy it is to work with would be a good thing to start.

Violet Page: Yeah, "Penn&Paper™'s Progress Tracker 8.3 Personal" is very easy to work with indeed! You start the application, and it automatically opens a sheet. Then you may just select a Pen tool

and draw a couple of lines. You can draw straight and freehand lines—whatever you wish, there's no limitations! This is all what it takes to draw a scheme of component distribution of your application.

P.S. Allright, we'd get a diagram of a component's architecture. But what about progress?

V.P. Oh, that's also easy. Just select a Marker tool,

and apply it to the parts of the system you've implemented

You can apply it to the interfaces and implementations, depending of what you've drawn with a pen tool in the first place. You're free to shade your items partially, and to use different colors.

This way you'll clearly see that the parts you've already implemented are shaded, and those you still haven't—are not.

As you gradually progress in developing the system, you'll shade more and more parts.

And more parts

Until, finally, you implement everything you've planned for the release.

P.S. You said I can draw freehand lines, but what if I just want to type some text?

V.P. That's easy to accomplish through the very same "Pen tool". Just user the context menu and select "type text" item. The text tool supports UTF-8, so you don't have to struggle to type symbols in your native language

P.S. What about teamwork? You know, you usually track progress not just to please yourself. Rather, one of your primary objectives is to provide a shiny picture for your managers and peers. How could I share results of my work with the other developers?

V.P. You have two options here. First, you can take a screenshot, and publish it the way you prefer.

You can post it to your corporate wiki, or mail to the parties interested. Or just make an animated GIF out of it:

P.S. What's the other option?

V.P. Our "Progress Tracker" integrates smoothly with the other "Penn&Paper's Solutions™" products. For example, you may seamlessly re-play your progress when you're having a corporate video conference call with "Penn&Paper's Conference Table™", so that your peers could envision the roadmap of the discussion:

Check out how the developer covers more of the diagram with his Marker tool as he explains the architecture of his software:

The other useful way of integration for collaboration is posting your work onto a "Penn&Paper's Blackboard™" knowledge sharing tool:

P.S. Hey, wait a minute. Collaboration over the same sheet usually causes merge conflicts. What can you do about them? The format you employ is obviously binary, and automatic merges are impossible... aren't they?

V.P. Yes, it's impossible. We adopted a technique familiar to many developers. Your colleagues may just "check out" your sheet (like in older revision-control systems), discuss it, make amendments, and then put it back to your workplace. We think that it's the most natural workflow.

P.S. What about protection? Are my sheets foolproof?

V.P. Well, for any protection there's a person stupid enough to bypass it. However, we provide some protection functionality. The first is the notorious "Trash can", into which your sheets are placed if accidentally deleted.

You can recover them easily from the "Trash can" unless it's really stuffed, and your sheets are disengaged.

However, the Personal Edition doesn't support Undo functionality. For this feature to work, you have to purchase one of our corporate products, such as the aforementioned "Blackboard":

P.S. Alright, so we've observed all the major features. But what's the price?

V.P. We've adopted a pay-as-you-go licensing model, popular in business applications. For example, for 4.95 you may paint 15 miles of lines without restrictions to the number of components you draw, or any time limitations! Our competitors require much greater funding.

P.S. Indeed, I drew this whole system, and the 5$ license isn't even half-used. Mrs. Page, thank you for the interview, and good luck in your future affairs!

Conclusion

So, unless you're dumb, you have already understood that it all is entirely fictional. You know, a whole generation emerged, of people who only saw floppy disks on "save buttons". And here comes a generation that discovers the stuff that surrounds them in their offices by studying allegations in software products, with which they (we) are much more familiar.

Of course, I'll continue to use "Penn&Paper's™" products. In fact, we're currently using one of them, the "Penn&Paner's™ Blackboard" referenced above, which is extremely useful in our Scrum daily meetings. I also have made a quick overview of "Penn&Paner's™ Table Scroll Sanitizer®", an open-source alternative of which I developed. I'm looking forward to more interviews with Violet Page, and, actually, to a small discount on their products >__<.

Yes, Scrum is now 100% buzzword. We learned about it in our university studies, we heard about it from corporate software engineers and consultants at the conferences, we see it in enterprise (see v1), we read about it in job postings, and some GSoC projects even impose Scrum to one-man "teams"!

However, it was not until this summer when I learned that it's actually an effective engineering technique. It revitalized the development of one of our projects (I'll later refer to it as "the Project").

Actually, the idea of adoption of Scrum was mostly inspired by one of our customers. A couple of our specialists worked in collaboration with another company on their product. The customer used Scrum, and held meetings in the room where our group sits. Our managers liked it, and we decided to try this framework.

So, we adopted Scrum for our project as well. When the idea emerged, I made a blog post referring to this idea as of a thought of a bored manager.

To make things less boring, I volunteered for a ScrumMaster role, and we spent three sprints (before we took a pause since the majority of our team went on vacation).

So, I've learned some lessons, and I want to share my thoughts on what Scrum is and how was it applied.

How I understand what Scrum is

First, what is Scrum. I won't repeat all definitions (you can find it on Wikipedia (frankly, quite a bad article) or here), just my perception of what it's really all about.

(To read the rest of the article, you should know base definitions of Scrum.)

Scrum values:

• permanent formalized evaluation of the work done
• early identification and discussion of problems
• frequently changing local goals (as an Agile tech)
• orientation to business values

The most important thing is the permanent evaluation. In the beginning of the post I mentioned that Scrum was used in a GSoC project. Of course it hardly was anything else but a disciplinary measure.

Early discussion of problems is also a valuable feature. During daily scrum developers are to speak about problems that prevent them from achieving their future goals. This is a required part of daily scrum, and it appears to be a valuable measure to keep things on time.

Frequent changing of local goals is a natural feature of any agile framework. Scrum's not an exception.

Orientation to business values is provided by separation of those who do the actual work (programmers) from those who make decision of how the product will look like (product owner). When we started doing Scrum, I noticed that nearly all items in my TODO list were replaced by the more valuable ones.

Scrum implementation

Scrum is not easy! Formal definitions say what should be done, but not how it should be done. I volunteered as a ScrumMaster, but only on the 3rd sprint I succeeded in leading a proper sprint planning. Scrum looks more like an interface, in the frame of which you can vary the actual implementation.

I can't explain every single nuance of our implementation. We have only established our way just moderately. And even if we would, it's a material for a 100-pages long book. Books is what you should pay attention to. The book that influenced our scrum the most is "Scrum from the Trenches", you can find the link at the "Acknowledgments" section below.

However, here's a couple of the most valuable notes.

It appeared that planning poker is really useful during the sprint planning. Contrary to what you may think, it makes sprint plannings faster, as it brings in a formal pace of how the meeting should flow.

Some people suggest that sitting at the table and walking through the backlog is not effective. However, for our 4-man project, it's, in my opinion, the best way to hold it. As we play planning poker, I (as ScrumMaster) make notes about separation things to tasks, and after we select enough stories for the current iteration, we go through the notes, and form the actual tasks.

Downsides and lessons of Scrum

Responsibility

The first, quite a non-obvious consequence of adoption of Scrum, is that it makes developers even less responsible than they usually are :-). People start doing things not because they should, but because it was planned, because there's an action item, and you can't close it unless you complete it.

Motivation of developers

As I mentioned, Scrum teaches to talk about future problems, not about of the solved ones. However, this leads to underestimation of effort the developers made. If someone has successfully solved a tricky problem, and thus made the underestimated story completed on time, it's not possible to detect it in a usual workflow. This makes developers less motivated. To overcome this is a task of the managers, and Scrum doesn't help here.

Inflexibility

Scrum silently assumes that estimation of how much it takes to complete a task can be completed within minutes. To estimate all stories and tasks, (usually 10-20 stories) only 4-hour meeting is allocated.

It is probably true for most well-developed commercial projects. However, our Project was partly a research one, and it was unclear how much time an implementation of something that wasn't really done by anyone else before would take. For example, evaluation of one of the features in our project took a whole week!

We solved this problem by

1. making sprints shorter (2 weeks long)
2. introducing "research stories"

When the "product owner" required to implement such a story, which needed additional research for its estimation, we first asked him to add "research story". An outcome of a "research story" is not an implementation of the feature, but rather a report that contained evaluation of several ways to implement the feature. Of course, several approaches to the problem have to be prototyped, but the quality of such prototypes shouldn't make the developers spend too much time on them.

The report is analyzed upon a completion of such a story, and one way to implement the feature is selected by the product owner. Then implementing of this approach is added to backlog, and is to be addressed in the nearest sprint (or the owner may decide that the feature is not worth it).

Of course, to increase the pace, we made the sprints short (2 weeks is commonly understood as a minimum value of sprint length).

Lack of code quality criteria

Tasks and stories are required to speak business terms. However, what if there's a need to refactor code, to set up a new logging system, or to fix the architecture with no obvious visible outcome?

The standard way is to decrease the "focus factor", and let developers decide how to spend the available time. If there's a great need for refactoring, there's a limited amount of time to be spent on it.

Prespecifying focus factor also makes the team choose wisely what to refactor, as they know they can't spend all the time on that.

Who fixes the bugs?

Some bugs are planned, but some are not! Some bugs get reported by critical customers, but--surprise!--all your working hours are already allocated between different stories. Who fixes the bugs then?

The obvious solution would be to allocate some more time on fixing critical bugs into the "focus factor" mentioned above. Non-critical bugs with lower priority can be made stories for the next sprint.

Scrum requires robots

Integrity and uniformity of the team is required for Scrum to work well. Days off are local catastrophes, and a sudden illness of a developer is a great catastrophe, which may result in a failed sprint (we're experiencing this right now).

It's obvious that Scrum would work for robots better, than for humans. However, if such a problem occurs, it requires really non-formalized, "human" thinking to resolve it.

Acknowledgments

The most fruitful source of information on how to do Scrum was "Scrum from the Trenches" (free pdf version). Shyness aside, having read Wikipedia definitions and this book, I became not the worst ScrumMaster in the world.

And, of course, experience matters. Our managers, Vladimir Rubanov and Alexey Khoroshilov, helped the team a lot to facilitate Scrum efficiently.

Conclusion

Another interesting thing I noticed, is that working without any formalized process is more boring than with it. Some time ago I assumed that it's like having sex in a new position, and after I tried that (Scrum, not sex), I realized that it was a very exact guess.

Though not ideal, Scrum appeared to be a very effective framework. It comprises both agile values and what commercial development wants, thus being the most popular agile framework. Its bureaucratic procedures (maintaining a backlog, doing scrums, drawing burndowns) are totally worth the net positive effect on development speed and quality.

As you probably know, I work in the software engineering department of a scientific institution of Russian Academy of Sciences, and my research and area of interest is software engineering. According to tag cloud, the "software-engineering" tag has reached the popularity of the "fun" tag; it does demonstrate my inclination.

But it was today when I wrote my first unit test.

And I loved it. Seven hours of ceaseless coding, brains not involved. Framework that runs it, hack to build system that assembles test application, mock objects controlled by environment variables -- that's how a bash/perl application is unit-tested, and that's totally not interesting. However, it was fun. I discovered two bugs in my application just by writing some unit-tests. Otherwise, I would delay the work, when we would encounter them later.

Unit-testing and automated test systems development

My whole career was devoted to developing automated testing systems. I was totally aware of why the tests are needed--it was the source of my income, actually. But why I never wrote unit-tests?

The answer to this question is simple. We, testing systems developers, get tests for free.

Usually, when you develop a testing system, you have a customer, whose software will be the primary target of it. Most likely, this software has several versions. And these versions differ dramatically from the viewpoint of a tester: the next version has less critical bugs to detect than the previous one.

And here's the test data. Just load the stuff you are to test! And here they are: a lot of regression tests for your tools.

The tests are essentially for free: you don't even need to think of test cases: the comparison with testing previous version yields enough information to decide whether your release if OK. And if you have another level of indirection, such as "test each version under each major Linux distribution", then you're likely to satisfy any vendor with your level of QA.

So if you happen to purchase an automated testing system (or merely have it developed), ask developers what kind of testing they made. If they somehow happen to have no regression tests, then it means that something's really wrong there. Because having such tests for free is an opportunity experienced testers wouldn't miss.

Recently I visited a conference for beginner scientists and engineers entitled Summer Young Researchers Colloquium on Software Engineering, and presented my paper On Reasoning about Finite Sets in Software Model Checking. My talk wasn't great--mainly because the research didn't yield the results it was expected to. However, the post is not about this.

Most of talks weren't very inspiring. However, some of them revealed interesting ideas that concern availability of programming.

Service-oriented development

The first talk, devoted to service-oriented approach to programming, was given by invited speaker Dr. Prof. Tiziana Margaria-Steffen from Potsdam University.

The main idea of her report was that software development is unnecessarily complex. Software Engineering, the discipline that studies the craft of creating software, mostly addresses issues of how it should be made, not what should appear at the end. However, if we switch focus to the services that software should provide, we can make the development process different.

She later passed on to the system that demonstrates the success of such a focus shift, jABC. Its main purpose is to separate business logic from implementation of the concrete components, and have a nice graphical editor of the former (see side note).

Of course you heard about such systems a lot of times. Of course, I couldn't stand trying to find out what's so special. According to Tiziana, that system has been developed for over 15 years, and still isn't dead. The reason is that the business logic was constrained to having absolutely no synchronization between concurrent processes; an only parallelism supported is fork-join parallelism: spawn a constant number of threads and wait for them to finish.

But of course, expressiveness isn't the main feature of such systems. The main one is that it allows non-programmers to construct programs. In my opinion, however, if a person is capable to create a runnable flowchart, he already has enough skills to do it without any "flowchart-driven development". Tiziana's answer to my question about that was that to create a program, a certain amount of skills is indeed required. But if you need to slightly modify the program already created by someone who has enough skills, you don't have to bear them as well.

After I poured upon that, I agreed that it's possible. Perhaps, the reason is that minor modifications require the skill of reading programs, not the skill of programming, which is necessary to creating them. And it is such "flowchart" systems that make this possible. And it means that more people will be programming.

Not-so-natural language

Another report that interested me was the one given by Andrey Klebanov from SpB ITMO. It presented yet another system that verifies automata-based programs, but it had a minor issue which is, in my opinion, more profound than the rest of the work.

The specification for the checker should be written in English language, constrained by a specific grammar. The specification language, which defined some kind of a temporal logic, had a grammar which contained natural-language sentences! So the requirements would look like this, literally: After the red button was pressed, in the finite amount of time coffee will be made. (instead of a temporal logic formula "Button -> ◊Coffee"). And what is important, these requirements will be processed by a machine.

Anyone who's familiar with maths, and who is a specialist in software engineering would argue whether it's convenient. Such enormous amount of unnecessary text in conjunctions and pronouns would anyway make specification writers auto-generate them from a more succinct format.

But I later realized that this system has an important benefit. It increases the availability of specification writing, lowers the bound of education necessary to write a machine-readable spec. If a highly-qualified specialist is to write such a spec, it will convert it from a succinct notation--but such conversion would anyways have been made. Abstracting away from the natural language, writing temporal logic requirements in mathematical notation requires certain skills, which not everyone possesses. So you could hire a less qualified programmer to to the specification writing job. A "natural" language notation should make writing requirements in a formal way more available, more cheap, and increase demand for verification tools.

Are the programmers still needed?

Of course, the increase of availability of development arises sad questions. Will we, the programmers, be needed by mankind in the future? Will we be the new Luddites?

I think, we totally will. However, someone has to write and maintain programs that will replace us. Someone has to make a relevant research. Communications of the ACM May 2010 issue presents an article about the (still research) prototype of a genetic algorithm that fixes bugs in programs. Today it makes most of us smile. Soon the smile will change to grin, and then--to panic.

However, I will not worry about that. It's natural, at the first place. Also, the first parts of the process that will be overtaken by robots and by low-qualified workers are the most tedious aspects of programming. Fixing bugs by digging into stacktraces, writing integration code, writing tests, creating specifications for complex obsolete programs will be the first to automate and outsource. What will left is the pure art of programming, that small piece of our work we all love it for. There'll be enough of that for the rest of my life.

And my kids will be lawyers.

At the meeting today we thought that the idea of our bored manager (you've seen it in Dilbert) to adapt Scrum is not so bad. It seems we're experiencing sudden attempt to use yet another cool software engineering framework; that is all developers usually don't like. Having been unusually and weirdly excited about such a commonly undesirable change, I tried to figure out why's that...

And I think I got it. Tomorrow we're trying to try a new sex position with my beloved wife. Yes, I lately realized that I'm totally married to my job (which I unconsciously referred to in a recent blog post). And the excitement is that we're finally going to switch that missionary position to something new and with more... movement, I guess.

But then I suddenly realized. The whole software engineering thing is just a large group sex Kama Sutra.

Just look at it.

"Agile methodologies" will totally require you being in a good physical shape to satisfy the project and do a lot of different things for that.

Scrum, with all its "chicken" and "pigs" being a reference to "men" and "women", requires rhythmic moving. However, I think, constantly questioning the partner whether things go well doesn't work well in the bed. Hell, "think"; I know; you too do.

Some techniques are even worse, however. "Extreme programming", that values fast delivery, isn't that women usually want. And this DSDM technique... I don't think it needs further explanations.

Of course, while in nearly every domain of human activity you can find sexual reference, it was funny to look it up in software engineering. However, it appears to be not that funny as I expected. So, basically, tomorrow I'm having a new sex. Isn't it what 80% of blogs are about?

Imagine that you have a project of a medium size, and you need to add a couple of functions to it. The whole system is a complex program, and is debugged by printing traces to a log file. So you've implemented a half of the new functionality, and you'd like to check if that half works more or less correct. Of course, you have a couple of your personal test cases and know how should the resultant execution trace look like. But the problem is that part of your system is a stub, and you can't get the desired trace, when an important part of system is not actually doing anything.

Another case: you have a program that runs in a complex environment, and you want to check how program operates when a series of similar queries to this environment yield specific output. You can, of course, implement a proxy that mimics the desired behavior, but you're lazy, and want to do it faster.

In other words, your program queries the environment or the unimplemented module (we'll treat them equally from now on), and you want--for debugging purposes--to make these queries return specific values without spending too much time for implementing a stub for a query handler. This can be achieved with what I call randomized debugging.

Two kinds of modules

There are basically two kinds of modules.

A module of the first kind yields as its output a "tricky" data structure that has complex constitution. If it is such function that is unimplemented in its stub the structures should should be restored keeping all their complexity and consistency. In this case, you really don't have a choice and consider creating a full-blown proxy to mimic its behavior.

In the other case, it's different. A module of a second kind is complementary to the one described above. As its input it gets a complex structure that contains a lot of data. And it behaves as oracle: its result is of a type with a small value range; say, a boolean. The modules of two kinds can behave in a nice pair, as shown on the sidenote picture.

No wonder that such a boolean, provided it is not to flag an "exception" of sorts, branches the program execution dramatically. And it is a specific series of values of these booleans returned which we want the stub to yield, as said in the introduction.

However, since the algorithm is not very simple, and a lot of different factors influence the output (remember, input data are complex!), it would take too much time to implement a stub precise enough. First, we should parse the input correctly. Then, we need to implement a state-machine that remembers what had been queried before and picks up the next result. That's too complex, while we need a fast solution.

The solution proposed is simple. Just replace the unimplemented function with a random number generator. Then run the test several times until the execution trace fits the desired behavior.

"Fuzz testing"? No.

Note, that this is not for testing. This is for debugging; the system is still in not a good shape to test it. Unlike the similar "Fuzz testing" technique linked to by silky in comments (it is to use [semi-]randomly generated data as test input) the randomized debugging achieves different aims. While the former aims catching the untrodden execution paths, the purpose of the latter is to make an unimplemented module to process the given tests correctly in one out of several runs.

The other, "unlucky" runs, when the random generator didn't hit the desired result, might be of some value to the developer, but that's not the aim of the whole thing. For "Fuzz testing" such tests are of primary value, as its aim is to make the program trigger extreme cases. The aim of randomized debugging is to make a system without parts execute as desired with little effort, at least, sometimes.

Where randomized debugging works best

Of course, it's not that good if the function is called several times, and thus you may spent quite a time running the test until it goes well. However, certain programs fit the idea of randomized debugging well. These are the systems that run in a loop, which is terminated when an unimplemented module returns a correct result, the wrong result doing no harm to the processes you want to check.

And of course, the less times the unimplemented subroutine is called, the more effective randomized debugging is. If you call it only twice, and it returns boolean, you'll get the correct execution path in 1/4 cases, no matter if your program is organized in the specific way described above.

Conclusion

Certainly I'm not the only one who noted such a simple way of debugging programs. I'd be glad if you provide links to the similar stuff. But whatever, it's simple and uncommon approach to rough debugging, so it's worth being a blog post. Let alone that at work I successfully used it a couple of times.

Recently I answered this question on StackOverflow, but I'm afraid they'll do something with my post, so I'll save it here.

The question was about code-stealing prevention features. It specifically mentioned if Visual Studio Team Edition contained some features to aid repressing the developers. Well, here's a couple of my advices:

My advice on how to prevent code-stealing by employees

The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".

Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors after they leave your company. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".

To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...

Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches that your don't discriminate disabled programmers.

"Sorry, couldn't help posting it." said I to StackOverflow, but here I'm not sorry, since it's my blog.

My on-field NDA experience

By the way I signed a non-disclosure agreement once. (And now I realize that if I disclose the information about it I will violate the agreement. So, I'm going to skip some text with logical reasoning, and proceed directly to the conclusion). The conclusion is simple: code stealing protection measures are just useless.

In programming, there's a concept of quine -- a program that prints its source code (wiki). I'm not obsessed with the concept, but it is fun sometimes.

***

Recently I saw this Dilbert comic, and It made me think about a funny thing.

"Oh, okay. It will cost you 50$", might the lady engineer have said, and written the following program:

Requirements that require a complying program to print themselves? Sounds like a software engineering quine, doesn't it?