Every developers know the importance of source code versioning and how to use SVN, Git etc to achieve but DB versioning seems unfamiliar and more difficult to most of them. But in my opinion, DB versioning is as important as source code versioning, especially when you are working in an Agile project where whole team is responsible to the environment. In this post, I try to describe the common issue with DB and how to solve this.


Most of software use DB now and of course, it need to be changed during the development and shared with the modules or whole system. And its problem is exact the same as source code where everybody works in only 1 source code repository at the same time:

  • When a developer makes a DB change, how can others aware it? It seems so easy with the source code with SVN or Git because they support the check-in, check-out. So before committing the code, a developer can view the log, see the code changes by other’s check-in.
  • When conflicts occur, how can developers aware and resolve them?

Why do you rarely care?

Let start with the traditional software development process, where the DB:

  • is built in the design stage
  • and it’s mostly fixed during the development.
  • and it’s taken care by a deployment person or team who normally put in charged of environment configuration.

So the developer doesn’t need to care about this. But in the Agile project, its design is unfixed as we may has increments, code or structure refactoring, and the DB schema is often updated sprint by sprint.

What do you usually handle? And their issues?

Follow my experience, there 2 normal ways we are using to handle this problem:

  • Shared environment. The easiest (and sometimes it is the best way) is using shared environment. For example, a developer works on his checked-out source code individually but query on a single shared DB server. It seems a good way but still facing some issues:
    • Performance. Normally it speeds is not as good as using local environment because the shared DB needs to serve all developers’ uses while the local one is more specific on the current module. And it may affect to the productivity.
    • Revision. It so hard to manage the DB revision because it need to go parallel with source code revision where we sometimes roll source code back to the good one. One solution is storing all the DB backup for each commit, but it takes a large amount of storage.
  • Scripting the changes. Whenever we have change on DB, script it and apply to all developer locals. It is the good way to reduce the storage and make easier to version the change. But how team members aware that the scripts are updated and resolve the conflicts?


DB versioning control

DB versioning control is an approach to keep track the changes on DB schema and data in a shared repository to make sure that team can aware and apply these changes easier.

How does it work?

There are some ways to implement the DB versioning but the most popular one is versioning DB by versioning its change scripts. So the DB versioning problem becomes the source code versioning problem that is solved really good right now.

The details of DB versioning implementation are vary project by project but the key points usually are:

  • DB changes are built by scripts. To reduce the storage and easy to update, we should script DB to files and arrange them in a good structure.
  • DB is under the source control. After scripting DB to files, it makes sense to keep them under the source control because they are the source code now.
  • The DB changes are verified during the project build or application start-up. It makes the developers aware changes that need to be applied. In my opinion, the verification should occur as soon as possible to avoid wasted time. The application start should be failed if the changes haven’t been applied. But it’s better with the failure during the build stage.
  • The DB versions are stored in the DB itself. It’s a good approach to keep the solution simple by for example, a table that stores the run history.

Better solution?

The purpose and a good approach is described above, but there are various specific solutions from project to project. I will have another post to describe an hand-on implementation in a specific project later but you should try to go further by this start as I think DB versioning is very important in Agile projects.

Reference: http://www.infoq.com/articles/db-versioning-scripts

1,195 total views, 1 views today

The introduction to Scrum in TapLife, shared in 2 hours with the product teams.

After a short introduction, they talked about the current context to get my shares.

Taplife is a startup, building some great mobile apps that are focused on the augmented reality. They are facing some common startup issues: looking for the effective working methods in the software development as they “seem” be following waterfall right now by the content team goes first with full specifications, design team make them visual on UI and developers end up by code implementation. It of course takes more time to make an idea go live.

964 total views, no views today

Yes, it’s me – Mr. Coding Tools.

I’m a fan of whatever makes our lives better. Most of them are the tools, right? So someone calls me “Mr. Tools” but it’s not true,  I don’t just use the tools. I’m a Mr. Coding Tools.

What makes a developer different? He can make the amazing tools for on-demand needs of his life, usually are once-use tools. When cannot find an appropriate software for reducing manual work, a rich man can hire people for building it, a normal man needs get back to his boring things in the hopeless, but a normal developer can do it himself. He always feel excited by doing in a smarter way although it sometimes takes more times than doing manually 🙂

When I was 17, the vice president of my mother’s school asked me “I want to show up some texts and photos on the projector board by a cool way in an important meeting next week. They should run from left to right, top to down etc. I have seen it when visiting a conference but I don’t know how to do it on my computer”. So easy with Power Point? Right. But what should you do if you don’t know Power Point? In fact, I had never known Power Point was existing that time. I had my first computer when I was 15 but just used it for programming to solve some algorithm problems or editing with Word to earn more money sometimes. I hadn’t known Internet as well because of its high cost. Borland Pascal, Delphi, Word, NC and FIFA were only my 3rd party softwares I had and known that time – so different when you guys were 17, far ahead from me.

“Yes, you can. Please give me the texts and photos you want to show up and I will get back tomorrow”, I said. What did I do? I wrote a Winform application with some areas for texts and photos, some timer triggers to scroll them in some directions. It was so easy like eating an apple.

“It looks good but could I change the texts and photos myself?”, he said when I got back. “Of course, let do it tomorrow”. And I changed my code for reading texts from files, get a photos from specific folder by their ordered names.

“Yes, it works but could I change the position of these texts and choose the effect myself?”. “Sure, see you tomorrow”. Then I went home, changed my text areas to placeholders and made their positions and sizes  more flexible.

“Super cool, we got it. I can prepare the content for the meeting next week now. How much should I pay?”. “Base on the success of your meeting. Give to my mother, I don’t care”. “Could I use it for the meeting next year?”. “Sure, or next month if you think it would help, otherwise drop it out”.

I believe Agile is in my mindset as long as I know building the software. Iteration, feedback, refactor, minimum viable product etc are so natural and come easily.

2 years later, I laughed out loud at the first time seeing Power Point, “OMG, I reinvented the wheel”. But I was proud of building the useful tool in my limited resource and knowledge. I came back, installed and trained the vice president to use Power Point but he wanted to keep using my tool as he had used it well 7 times for 2 years. Because this tool was enough for his needs and Power Point has too much features but didn’t have Vietnamese user-friendly UI. Simple but enough is better than tons of no-use add-on.

In my career, I has built a lot of tools for myself and see it as the best way to improve both my coding and customer-side thinking skills.

Some days ago, I created a backlog for my next 23 months and I’m thinking about creating a mobile app for tracking as unfortunately I didn’t find any right tool. Again, it maybe a one-use tool.

Sometimes, no tool is better but guru should do build tool.

1,625 total views, no views today

In the conferences and meetup, when I ask people “What are you doing? (in your company)”, I usually get these answer “I am a project manager”, “I am a team leader”, “I am a CTO”. OMG, too many PMs, CTOs here, where are our developers? These conferences don’t just open for the management positions only.

Then I found that some of them just tell me their titles, not their real jobs. It seems similar to the case of my friend, Bob, a very talent and skilled developer, became a project manager (PM) and then CTO after graduation and joining his company in 4 months. He is of course right to tell me his title but does he know what jobs need to be done by a PM or CTO? Why should a small outsourcing company, that does every project it could bid, need a CTO?

Let’s see the definition a common title (by Wikipedia):

Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

And look back to Bob’s daily work. How many time share of his daily coding in his project? 50%, 60%, 70% or 80%?

80%, sure, Bob is not a PM, he is a developer in PM title. Even though he choose 50%, he is still a developer. It seems a common case in a small company where the number of PM equals to a large company.


There are 2 reasons I see.

Small project. A small company usually does a small project with team size is about 3 to 6 members (sometimes 1 or 2) compares to large team in a bigger company.

Benefit. Company gives Bob a title (and may pay a little extra money for this title) for getting a very big benefit from him. Life is not fair. Bob feels more important as being a PM of project? Sure. Bob is mainly responsible to the success of project? Right. And what would Bob do? Double his work hours day by day. If you are a best technical and skilled guy but work in PM title, it would be a nightmare. I guess Bob hope that he is not good at technical. But if he is, it’s so difficult for Bob in getting the chance to have PM title. It sounds funny.

The pitfalls

Renaming jobs by a title this way may bring some issues to the both employee and company sides.

Bob thinks that he has enough knowledge and skills of a PM and doesn’t want to be a developer so far although he is still a good developer and bad PM in a lot of successful projects. Some months ago, I had an interview with a good candidate who truly believed that TL or PM is a position suits him and didn’t want to be a developer any more because he have worked as PM for 3 years and completed some projects well. But I asked him “How many teamwork issue did you find in the most recent project?”, “Hmm, 1 or 2”, he said. “You seems not a good PM. No matter with your teamwork issue, 1, 2 or 100, how you answer me with “hmm” and “or” shows that you didn’t monitor and control it well”. Yes, he didn’t monitor project as he should do because he spent too much time focusing on development. He was just assigned to PM position to fulfil project roles and couldn’t get enough time to do the main tasks. But it’s so hard for me to convince him joining us in a developer title although every developers manage works and the technical stuffs themselves here. The title illusion has killed a developer’s career softly.

It’s unreasonable to promote the best developer to PM position where he can show off the bad management skill but why is it the common way we are doing? It seems an easiest way to keep him here and reach out his coding competence – but it just works in a short term. If we still want, please keep him out of coding time (or at lest, have a plan to decrease it), he need to have overall view of what is going on in this project while the team is working.

The project cannot scale that way. Sure, developer is just a developer even though he is in PM title for a long time.

It’s exact my case in some years ago when I worked for a small company in several small projects and was proud of how they introduced me, PM or “Web product director” sometimes, until I spent a whole day to look back what jobs I had done, how much time shares I had spent for in this project. Then I quit thinking that way. We cannot change our jobs by just renaming them. And I see it’s the common case of the young guys especially the graduated students who always have big ambition and want to quickly have big steps in their career path. But they don’t have enough knowledge to identify it’s just a trap by the title outside.

But why shouldn’t Bob answer me “I am a developer”? I don’t know, he may feel better by “I am a PM”. But I believe in some next years, Bob may say “I am a developer, a guru”.

Let the daily main jobs set your title.

907 total views, no views today

It’s my presentation in monthly meetup of Agile Vietnam in May, 2015. In 2 hours, I shared our case study about applying Agile in both working environment (by promoting flat-management) and software projects.

I also got a lot of feedbacks and questions and highly appreciated. Thank you for joining.

748 total views, no views today

In 2013, HanoiScrum had a program Agile4U that brought Agile to universities in purpose of enlarging our Agile community. We thought that the IT students who will work in the modern projects should know Agile as soon as possible and be aware of the trending of software development method because their courses were full of traditional approach and no longer updated.

As the main in charged person of this program, I had some talks in several universities such as University of Engineer and Technology (National University, Hanoi), University of Science and Technology of Ha Noi… etc. I used to use this presentation that was built by Tan Trong Duong and me with some customizations for the specific talks with the case study or game.

After a year, we decided to stop this program. I was so busy that time with the new job (the talk was short, but it took a lot of time to contact and organize an event in an university with a lot of ugly stuffs, especially in procedures). But the main reason is its values. It seemed to bring less value to the students because most of them didn’t have any experience in the real project within a process. It’s so hard to show how better Agile is than traditional approach. They might be impressed by my performance and the strange content but traditional methods seem much more easy to understand and believe on.

But I’m considering to restart this program because the universities seem different right now with a lot of students having the longer internship in the real on-job-training work. Then they can see the issues of traditional approach in the real project and maybe finding an alternative way. Do you think so? Or are you interested in an Agile course instead of an introduction talk? If you are a student, please throw me your opinion, I’m very happy to spend my time to make this course go live.

907 total views, 2 views today