Posted by: Jaideep Khanduja
when relevant content is
added and updated.
when relevant content is
added and updated.
A warm welcome to Igor Ješe to accept my invite for an interview. He is the author of popular mockup tool MockupScreens. Recently Igor has published an easy and straight-forward generator of real-looking test and sample data named as MockupData. MockupScreens was built in 2003 by Igor as a simple tool to use it for himself and a small group of analysts. Within two years it was a well known tool to professionals outside his known groups.
Please tell about your early school days?
That really brings old memories, let me see. I barely remember my school days before I was 10 years old, it’s almost like I was just a bystander in my own life before that age. Then something happened and I started to fight for myself, becoming pretty stubborn in the process. Being a parent myself now, I think I can really imagine the hard time my parents had from one incident to the next during those years.
What were your plans during your later education days?
The weird thing is that I was by far most talented for physics, of all things. But when the time came to choose my professional education, I couldn’t for the life of me visualize myself as a physicist. So I went with my second choice, which was Computer Science at Zagreb University.
Circumstances quickly changed though, and I had to support myself for almost the whole duration (that dragged out to embarrassing 7 years, to be frank) of my studies. So when my Master’s Degree came in 1999, I was already employed with IBM for years and my course was firmly set.
What expertise did you achieve during your college days?
I guess I was lucky back then: I was involved in one of the biggest IBM projects in the region at a time. For a quick-learning and determined youth like me back then, it really seemed like a vast fountain of knowledge and experience and a playground with wonderful sci-fi technologies I’ve seen only in the movies before that. I came out with more than working knowledge of DB2 and WinNT servers, so I guess I got more than unfair advantage over my fellow students in the process.
What career did you opt to start with after completing your studies?
For few years, I was quite happy improving my skills as a database guy in development teams. But soon I started to feel “left out” somehow, it was like important things were happening somewhere else. So I started to steer my career towards Software Requirements, because I decided that was in fact were the operative decisions were really being made.
Since how long are your engaged in Software Requirements and Development Methodologies?
Software Requirements came as an intentional career move, somewhere before 2000. But the genuine interest for Development Methodologies started in quite different manner. In 2001 several colleagues and myself joined the small high-tech company in the making.
But within months we were all pulling 60-hour weeks without any real idea how we got ourselves into that mess. So we as a group decided there must be a way to work smarter instead of harder, and busied ourselves with UML first, which quickly led among other things to RUP and formal Project Management.
After several years of testing and customizing heavily all the knowledge we could find for our own practical day-to-day use, the results were so obvious that other companies started to hire the whole bunch of us as “methodology consultants”, to do the same for them.
What is the tool that you have developed? It is meant for whom? What purpose does it suffice?
MockupData (www.MockupData.com) is a data generator, the tagline I settled on is “Make your data look real”. Basically it generates bulk data that looks like a real thing: real-looking names, addresses, etc. Software testers use it to populate the applications they need to test.
There is no realistic testing having the fields of your system filled with random strings and numbers that human being cannot relate to anything from the real world. And populating databases with “almost real” data in realistic quantity is either prohibitively expensive in human effort or simply not feasible – e.g. because of data privacy regulations.
How did you conceive the idea to develop this tool?
Actually I have needed something like this myself many times. Several times I have even implemented something similar for a specific project and specific database. And in 2003 I have even published a precursor to MockupData, as a joint effort with a friend. But we were quite inexperienced so the partnership hasn’t worked out, which was nobody’s fault really, but the product just faded out before it got any real traction on the market.
Occasionally I have used this first product for my own purposes afterwards, and it simply felt a shame that I couldn’t offer it to other people. So I finally started from scratch and MockupData is a result. With which I’m very satisfied I must say, and the early feedback is simply fabulous. Testers and database developers need something like this, to create and re-create quickly and at will different variations of real-looking data, and in thousands or even millions of records when needed.
How much time did it take to develop this tool and with what size of team?
More than a year with three people putting approximately half of their time into it. Which was quite longer than I anticipated. I thought that since I exactly new what we needed to implement it would be a fairly quick project. The core “engine” took only a few weeks. The whole tool only several months. So far so good.
But then we came to usability. We had many concrete ideas how to make ordinary tasks more smooth for the user but no ready-made support for them in wxPython, the GUI package we were using. Finally I hired a usability designer to help us out, a great Spanish guy that on and off spent months discussing with us different ways to implement most of those ideas, and then to test and re-test and tweak everything.
What is the development methodology you adopted to develop this tool?
I knew you would ask that and still I don’t have a ready answer for you Frankly it was a mix of best practices: implementing small fixed chunks at a time, tricky parts first, stopping for refactoring when needed, while continuously having a “clickable build” and continuously unit-testing everything except the GUI.
I believe in creating a team of great people and letting them work, and to tweak methodology to suit them instead of the other way around. Most techniques in any methodology are in fact trade-offs, and if something doesn’t work for your particular team and your particular situation – out the window it goes.