Teamwork – really?

It is a near perfect example for a perfectly competitive market with largely homogenous products providing us with the variety of choice. Most of these products have extremely steep and short maturity cycles without sustainable futures. Or, put simply, they exist to grab a small share of the market to make a quick buck. Regardless of whether the business has the vision of being a sustainable innovator or a one-shot wonder – one result is clear: To have a chance with an industry such as consumer electronics it is crucial to produce products with 'reasonable' quality (the one year warranty) in the shortest time possible (i.e. yesterday). So what is the key to efficient and rapid development of software and hardware? It seems we are always stuck waiting for someone else to finish their part of the project. So in order to produce rapidly we need to eliminate as many bottlenecks during the development and production phases as possible. In engineering we have traditionally segmented 'silos' or centres for software, hardware and mechanical engineering. What follows is a typical story: The software engineer can only begin developing code once the hardware components have been decided upon. So he is largely dependent on the hardware engineer. Once the hardware has been completed the hardware engineer is told by the mechanical engineer that the housing has changed. The software engineer then realises that he used the wrong version of code, so the hardware has to be reprogrammed before it can put through the inspection tests. The story continues with numerous iterations. The outcome of this example is that there are no transparent flows of information and no integrated systems to control the design data. Although these centres of expertise may be physically segmented there is no reason for the design data not to be shared live with all stakeholders providing that the appropriate security measures are in place. Take for example open-source software on the Internet; it thrives from multiple user input producing very high quality 'ironed out' solutions. Programmers can download a version, make their changes and submit their iteration back to the design vault. While the software engineering space has adopted this controlled versioning work methodology – also known as Configuration Management – for almost decades, it is only now that we finally see the appropriate implementations for other disciplines such as ECAD and MCAD. To the delight of development engineers and businesses, there are tools putting the theory into practice to achieve those tight deadlines, saving not only time but ultimately money. Ideally, mechanisms have to be in place that include managed version control infrastructures and collaboration, so that all parties in the development process have access to the correct and up-to-date information in a manner that prevents obstacles. The landscape of tools and services is changing here, and it is fascinating to see this happen from both the driver's seat by providing the new technology, and from the user's perspective, managing cumbersome tasks in shorter time frames, more reliably. Lars Ulph, application engineer, Altium Before joining Altium in November 2007, Lars Ulph worked as a hardware and software design engineer. He was trained in both mechanical and electronic engineering and his background currently includes a large variety of cad and space simulation packages, as well as programming for software and hardware applications. Lars holds an Honorary Bachelor of Engineering degree in Engineering with Management (University of Exeter, UK) and is an associate member of the Institute of Engineering and Technology.