Customer: “So you also do full projects?”

One of these moments when you find out that the company is not seen as I want it to be seen. Compared to generic software engineering companies, we have the advantage of creating software that is capable of processing more data.

For years we have promoted this unique advantage, for which we use OpenCL, CUDA, HIP and several other languages. Always having full projects in mind, but unfortunately not clearly communicating this.

During discussions with several existing and new customers, it became suddenly clear that we are seen as a company that fixes code, not one that builds the full code.

It became most clear that when was suggested to let us collaborate with another party, where our role would be to make sure they would not make mistakes regarding performance and code-quality.

  • Customer:   You can work with a team we hired before.
  • Us:             We also do full projects.
  • Customer:   Really?

This would mean we would be the seniors in the group, but not own the project – a suboptimal situation, as important design decisions could be ignored.

Roles for larger Projects

We have done several full projects and have designed the internal structure for it. We have defined these roles within the company:

  • Analyst. Creates a solution by understanding the goals, existing algorithms and the domain. We’ve been told during most projects that we are very quick in this “deep-diving”.
  • Algorithm Designer. Translates a mathematical algorithm to an algorithm that maps well to modern hardware. Here we put our years of experience to practise.
  • Performance Architect. Researches the optimal optimisation path for coding the algorithms and sets out the architecture. Together with algorithm design this forms our main specialisation.
  • Performance Engineer. Writes optimised code for the CPU, GPU or FPGA, according to the plan set out by the Architect. Also implements the low-level optimisations.
  • User Requirements Architect. Designs the user-interaction to make sure the software can be quickly used.
  • Software Engineer. Builds user-interaction, databases and glue-logic.
  • Project Manager. Plans the project and manages the team on a higher level.
  • Team Captain. Leads the team on a daily base and handles customer communication on a weekly base.

What was most surprising to our current customers is that our rate of the software/performance engineer is very comparable what they were used to. When we fix software, it is all done by analysts, algorithm designers and performance architects – those have a higher rate.

Why fix it later?

We’re trained in understanding complex problems quickly and to come up with new ideas. When we fix software, we isolate code, redesign its architecture and rewrite where needed. When we build new software we do this right the first time, reducing time and costs.

 

 

Related Posts

Example of modelled versus measured water activity ('effective' concentration) for highly detailed organic chemical representation based on continental studies using UNIFAC

Porting Manchester’s UNIFAC to OpenCL@XeonPhi: 160x speedup

...  needed 330 ms per iteration). The optimisations were also very effective on the CPU: using OpenMP on the CPU with XeonPhi ...

WebCL_300

Q&A with Adrien Plagnol and Frédéric Langlade-Bellone on WebCL

...  the desktop version includes OpenGL interactions, WebCL is also able to use WebGL buffers, even if this feature is described as ...

default

Random Numbers in Parallel Computing: Generation and Reproducibility (Part 2)

...  have stated last week – is an important matter for our customers. Reproducibility Reproducibility may be simple if random ...

GROMACS does soft matter simulations on molecular scale

We ported GROMACS from CUDA to OpenCL

...  was under NDA and we could not demo anything we made for a customer.  We chose for a CUDA package to port to OpenCL, as we notice ...