Thoughts from The Dev TeamMay 18, 2016
Ruminations on the development process – Part 1
Why I meet our clients
As I write this I’m sitting at the airport waiting for a flight
to Toronto. I’m on my way to visit clients. I will be there for
one day and then travel on to New York for more meetings. It’s
not unusual in our industry for company representatives, like
sales people, or training consultants to go and see clients. But
the head of software development? A little less usual.
For me and the other developers in our team, taking these trips
is important. They give us the chance to meet our users on a
regular basis. Insight into what our users do, and want to do is
essential to the way we design and develop the product we give
But working this way isn’t always the case. In many organizations
there is one team that designs the product and decides how it
should work. This team listens to sales, support teams and other
sources, after which they come up with a plan. This plan is then
translated into a product specification. Finally, the specs are
handed over to the developers, who do their best to turn these
specifications into a product.
With this many steps between the users and the developers it’s
not surprising that IT products are often disconnected from the
real issues experienced by the users.
So, why do IT projects seem to fail on delivering good products
From the Bottom up
I think a very common problem is that IT projects are often
treated in the same way as more industrial projects, with a
top-down approach. A team of engineers or designers, with highly
relevant knowledge, come up with a product plan. Then workers
execute these plans to produce the product. In contrast, in the
IT industry you’ll find that the process may be structured in the
same way, but the distribution of knowledge and skills is not. Of
course you need good management and project leaders, who help to
organize the work. But for the most part they don’t have in-depth
knowledge about software development. Naturally, the developers
do. So in this case, the typical top-down approach doesn’t make
so much sense. Unlike industrial projects, with IT projects the
people who have the most relevant knowledge are at the bottom.
Design is difficult without context
One way of approaching the development process is to have a
separate design team, who act as mediators between the users and
the developers. In this case the role of the developer is to
solely focus on executing the product specifications. I won’t say
that this never works, but you have to have a really good design
team that understands both the needs of the users and how to
develop software. In my experience, this is very rare.
The devil is in the details
A product specification cannot possibly cover all the details
that the developers need to consider. After all, a computer
program is just a very detailed specification of what the program
should do. In theory, if a specification contained all the
details, it could be transformed into a computer program and you
would not need any developers. Luckily for me, that’s not
All these small decisions, the ones that can’t be covered by the
specification, are really important for the end result. If the
developers understand how the product is going to be used, the
solutions they develop are far better suited to the users’ needs.
If you’re still unsure of whether it really is necessary for
us developers to meet our clients, look out for my post next
month when I’ll be mentioning some examples of what happens when
Your Overview of Data AdditionsApr 26, 2016
Thoughts from The Dev TeamApr 18, 2016
On hard choices, simplifying your workflow, and our new Python (API)
Welcome to the first in a series of monthly posts from the product development team. In these posts we’ll be giving you a look at what we’ve been working on here in Gothenburg, Sweden, as well as general ruminations from our department. I guess it will be mostly me, Thomas Olsson, writing these posts, but occasionally someone else from the team might join in.
We think that the Macrobond application is the best tool to use for pretty much everything our users need to do (not so strange, when you consider that we built it that way). That being said, there are some users who have not, yet, come to realize this, and so they continue to want to use other tools! Oh, the irony…
Allow me to clarify. Our philosophy is to offer the most commonly used statistical functions in an easy-to-use way. This sometimes means that we may not offer all the possible settings for certain analyses.
And with good reason! By leaving out features that are rarely used, we can make a more user-friendly interface. Which means more time for our users to do what they really want to be doing, instead of trying to wrestle with an unruly tool. Deciding what to leave out however, that is one of the most difficult parts of building a product. (Whatever else can be said about the man, in my view this was one of the true strengths of Steve Jobs, and essential to the success of the first iPhone. He dared to leave things out.)
What if you need more options?
That’s where APIs come in. What an API (Application Programming Interface) does is to make different applications collaborate. To give you an example let’s compare a workflow with and without an API. Let’s say you’re working in Macrobond and find some data you would like to put through EViews.
Without an API:
- Download the data from Macrobond
- Save it in Excel
- Open EViews
- Upload the data from the Excel file
With an API:
- Open EViews
With an API you can access the Macrobond data in EViews directly.
For a long time now, we’ve offered users the possibility to integrate Excel, EViews, and MATLAB into their workflow in the Macrobond application, via APIs for these programs. So those users who prefer to stick to the tools they know, or those that need features that aren’t widely used by their peers, can choose what works best for them. If you’re using Macrobond in conjunction with these tools and don’t know how to make use of these APIs, read this.
Macrobond + Python
Now we have added an API for Python to that list. Python is a programming platform, popular amongst financial analysts for powerful libraries like NumPy, SciPy and Pandas.
If you’re a fan of Python (the platform, not the British comedy ensemble, although naturally these things are not mutually exclusive) you’ll be pleased to know, when running Macrobond on the same computer as Python, you can:
- Use any time series, including values, dates, and metadata, in Python
- Convert a set of time series to a common calendar and optionally, a common currency
- Fill in missing values in a few different ways
- Upload your own series to your in-house database in Macrobond, which can then be used in the application and even shared with others
Downloading a time series and printing the values can be done with just a few lines of code:
c = win32com.client.Dispatch("Macrobond.Connection")
d = c.Database
s = d.FetchOneSeries("usgdp")
The API is included in the Macrobond application from version 1.15.88.
In the documentation on our help site you’ll find information about all the possibilities you have with the Python API, as well as many examples: https://help.macrobond.com/add-ins/macrobond-python-api/
Your Overview of Data AdditionsApr 4, 2016
Making additions to our database is part of the day-in-day-out at Macrobond, and up until now we’ve published a weekly list of the main additions made. From now on we will be publishing data additions every other Wednesday. But we’ll kick off this change with our first post today.
These posts provide a less time consuming way to get an overview of data additions. Posts might highlight trends in data requests from our users, point out some of the more unusual data additions, as well as provide updates on progress made in ongoing projects. We will also include some example charts to give you a sense of the type of time series these additions include. For those of you who prefer to simply scan the list- not to worry. The list of data additions by country, with links to the application, will still be included.
So, what’s new?
Many users have expressed an interest in expanded emerging markets coverage. For the latest additions we’ve focused on adding data for the Middle East.
Under any one category, the data included can be highly detailed, as well as consist of long histories. If you see a country or region that’s of interest to you, we suggest exploring the data within the application, via the links provided. It’s the simplest way to stay up-to-date on new series that could impact your analyses.
We’ve also made some additions for specific client requests. Sometimes we’re quite surprised by the level of detail these additions include. For example, if you’ve been waiting to investigate home building prices in Uruguay, you can now compare the price of a variety of 12cm bricks. No detail too small, as they say.
We will be back with more additions every other Wednesday, from the 13th of April. So check in then for the next review, either here or in your application news feed.
Residential Property Price Index by Region
Central Bank Balance Sheet
Deposits & Loans
Gross Domestic Expenditure on Research & Development
Home Building Prices
International BEA data addedSep 15, 2015
International dataset was added in Macrobond separate BEA database. This addition ensures all BEA data categories are now available in MB.
The data is available in this location:
BEA > United States > International
Direct Investment & Multinational Enterprises (MNEs)
This dataset contains two types of statistics:
||Income and financial transactions in direct investment that underlie the U.S. balance of payments statistics and direct investment positions that underlie the U.S. international investment positions.
||Operations and finances of U.S. parent enterprises and their foreign affiliates and U.S. affiliates of foreign MNEs.
BEA's international transactions (balance of payments) accounts include all transactions between U.S. and foreign residents.
International Investment Position
BEA's international investment position accounts include the end of period value of accumulated stocks of U.S. financial assets and liabilities.