Ubuntu 15 on Precision 5810 No bootable device found

Just registering a slightly off-topic note: the Dell Precision Tower 5810 firmware revision A05 has bugs causing problems with the Ubuntu EFI boot loader.

After installing in EFI mode, the firmware does not find the boot loader, causing the error “No bootable device found“.

The cause of this error is that the firmware expects the boot loader to be \efi\boot\bootx64.efi. On the other hand, Ubuntu Grub boot loader installs a file which is \efi\ubuntu\grubx64.efi.

Worse, the firmware overrides any value specified using efibootmgr

For example:

efibootmgr -c -l \\EFI\\ubuntu\\grubx64.efi -L Ubuntu
efibootmgr -v
ubuntu HD(1,800, [..]) File(\EFI\ubuntu\grubx64.efi)

efibootmgr -v
ubuntu Vendor(99e2[..])

To complete, the firmware configuration utility is equally useless. It lets select the right boot loader but does not persist the selected path.

Fortunately, this problem can easily be solved installing an updated version of the Dell firmware. I installed version A07 and everything worked ok.


How did it succeed ?

This project was doomed to failure.

  • Client involvement was minimal. There was no clear requirements definition, the client only appointed a business unit manager as single point of contact. But this manager had many other things to do, more important to her than “taking care of the system”. There was no infrastructure to support the system in production.
  • Requirements were complex: the system to build was a customized ERP incorporating the client’s business processes and rules – which were very different from what commonly exists. This ERP should manage contracting and offering, clients and prospects relationships, invoicing and payments, stock and inventory, bar sales, accounting statements and much more. And it had to be used in a multi-tenant model, various geographically distributed business units using it independently.
  • There was no room for late or low quality delivery. Not without reason (see above) a previous attempt to build the same system went wrong and the client had already lost patience.

Despite of this, the project was a great success. It has been developed on budget and now runs smoothly 24×7.

And probably the most interesting: it has been developed by a single developer. Working half-time.

I could write about the details of the process used, but processes should be implemented for a reason. And there is two fundamental rationales less frequently mentioned.

  • Manage your client’s expectations. Or, in other words: client confidence through contractor accountability. We repeatedly delivered what we promised thanks to an incremental development approach based on the agile principles. And we were very, very careful with requirements and change management. Be prepared: you will someday have to gently prove to the client that he is the responsible for some problems or delays.
  • Manage your software architecture. We were really intransigent about architecture coherence and code quality. This is a sine qua non condition for the development to continue at a constant pace. The system was too big to live with a technical debt. One key there is probably: maintain the design clean enough to allow for constant refactoring.

Note that I have not mentioned any technology here. Actually, the technology used, as long as it is a good fit for the system under development, is irrelevant. JavaScript, Java, Scala, C#, LAMP… whatever.

Of course, there would be a lot more to say. Do not hesitate to leave questions or comments

Software Project Charter

Most (software) project management processes recognize the need for an initial high-level definition of what is expected from the project. PMI’s “PMBOK Guide” for example defines a “Project Charter“. On its turn the UP has a “Vision Document” which is very similar.

Very similar but with two important differences:

  • Project Charter is business-agnostic, supposed to be usable in any project kind from building construction to off-shore exploration. Hence its Project Charter does not know anything about software development specificity or terminology.
  • Vision Document is actually a requirements document (it is not included in the project management artifacts) and thus lacks some important information at this respect.

I long felt the need for an “unification” of both documents, including what is recommended by the PMBOK and what is needed in the context of software development.

The result can be downloaded here: Software Project Chater Template


Restarting my blog. Once more. It seems that I just can’t stop blogging. Probably because I like to share thoughts and knowledge. My previous blog has been wiped out when I left Brazil… new life, new blog.

Anyway. As a first post I would like to share two previous works.

Software Architecture Document Template

The first one is about software architecture documentation. Project after project I try to enhance the structure of the “Software Architecture Document”s I write. I like the agile approach: write only the minimum information that is needed and useful. Or, in less empirical terms, write the documentation whose cost equals the cost of not writing it (an equilibrium that minimizes the cost of documentation). But I’m digressing. Digging in there could disinter a whole thesis. Revenons à nos moutons.

I also like to work toward a well defined and repeatable process integrating best practices, to avoid having to reinvent, redesign, rebuild, retest and redeploy wheels at each project.

Long story made short, I ended creating a SAD template containing both document structure, rationale and instructions. It can be downloaded here in OpenOffice format: SAD Template.

PMBOK Pocket Summary

Another aspect of my indefatigable, unceasing search for the perfect project organization, I got the PMP (Project Management Professional) certification from the international project management organization PMI. The PMI publishes regularly a guide to the project management best practices (PMBOK Guide). A very generic catalog of best practices that can be used in project management. A complete reference that is thicker than a bible and far less poetic.

Preparing for the certification I ended creating a “pocket guide” that i published on Leanpub. 88 pages of the PMBOK essentials. This book can be found here: PMBOK 5 Pocket Summary.