no more cubes

Blog

  • Change.

    Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

    While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

    These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

    At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.

  • Mix and Mingle

    The past weekend I traveled internationally to work with colleagues on another continent. I’m a lucky volunteering member of IEEE, and so I reached out to the community before I jumped on my flight.

    Turns out I have friends in this city, and so I spent a whole afternoon learning about the city and the eventualities it brings along.

    Both my old friend and me agreed throughout our conversation that networking is an important activity, and having built an extensive network is an enormous asset.

    While IEEE is only one opportunity to meet people, it is a solid recommendation for engineers to actually pick up this activity in first place, even though it may not seem obvious at the beginning of the individual career. Working with and knowing many people is all too often underestimated and need strong soft skills. But even those can be trained, just like engineering can be tought.

  • Lifelong Learning

    Lifelong Learning

    IEEE’s Educational Activities Committee (EAC) invited me for their regular meeting, that happens May 13th and 14th in Porto, Portugal. Me being there is to represent Action for Industry Committee (AfI). On first priority, the attendance is to foster inter-committee cooperation. However, one of the items we’d love to promote to industry, but to everybody else, is that education is important. In particular in Industry, where innovation and therefore differentiation from the competition is key to any activity.

    To make the point about lifelong learning: upcoming, innovative technology trends, just to mention the Internet of Things, Electromobility or Autonomous-Driving require broad sets of expertise’s, abilities and complex organisations to come to life.

    The Internet of Things, while being a vague term, is often associated with an App controlling a device remotely. While this looks easy on the outside, looking into the workings of such a product, it typically requires skills from 2 mobile platforms, Android and iOS, potentially Web. The connectivity part requires knowledge about transport protocols, that need splitting into IP protocols and constraint field busses. The cloud end alone is typically broken down into data transfer, data storage and data processing, while the field offers a broad choice of communication protocols and physical layers, all for different purposes and use cases. Not to mention the engineering, design, production process and supply chain that yields a physical device that a consumer wants to control. Adding in service based products, that give a customer a better understanding of usage patterns, energy savings, potentiation gameification of product use, require data processing and analytics.

    This very high level example requires at least 3 major degrees, again, not mentioning the business administration side, that’d increase the count to 4 major degrees, with about 3 minors each, just on the upside estimate.  Highly complex products like this need highly skilled engineers and managers, that do not only need to execute on producing and operating a device, but also keep up on technical ability to stay on top of upcoming technologies, processes and procedures.

    Lastly, any requirement to understand peering functions and technology makes the final argument for lifelong learning, because not only does the world change so fast, there is always fields interfering with an engineers major in an evolving market. This way, lifelong learning is not only something desirable to one self’s development, but a fundamental requirement to stay ahead of the market.

    IEEE’s main pillars are academic publications, conferences and standards, all carried by an overwhelming number of volunteers. These are all, with no doubt, convinced that sharing knowledge increases knowledge. The really differentiating fact for IEEE is these are not from a single domain of research, but these ~420.000 members are organised in 39 technical societies, spanning all different kinds of technology and research.

    Through this large spectrum of interest and the volunteering nature of the organisation, it enables lifelong learning through the exchange of ideas and knowledge alone, with Committees like the EAC fostering the activity, and Action for Industry keeping the relationship with engineers in industry.

  • Customer Questions

    Working as an IoT Product Manager you have to listen to your customers questions.

  • robotic loop

    Calling it an “accurate representation of whole western capitalist society” is a bit far reached, but it will trigger associations for the urban, corporate employed citizen. Everything working makes the journey very convenient, but go in circles.

    http://imgur.com/gallery/6e2XRNM

    via Nerdcore.

  • On Digitalised Product Management

    Again. Having read the few words from yesterday, it’s probably difficult to follow. So, let me try a bit more structured to write up on the points I was trying to make are:

    1. Product and Service Business are different cultures.
    2. Both have established methods.
    3. Digitisation requires Digital Transformation.
    4. Digital Transformation won’t happen without a conscious decision.
    5. Digitised Products need to consider both.

    Product vs. Services Business

    This is the part with the margins. While the first lives off high enough margins in the retail chain, the later lives off customer satisfaction, with basically very thin margins.

    Management Methods

    Things require a stock and supply chain. A service requires time to response and time to resolution. Or response time, for interactive services. And so do physical projects require different management methods than services do.

    Digitisation requires Digital Transformation

    Putting a chip in it is not the single answer to achieve Digital Transformation. It requires to combine product and services business and that process is the actual transformation people are looking at.

    Digital Transformation won’t happen without a conscious decision

    Very much as , just putting a chip into a product will not be sufficient, because the product will work so much different than before and the customers expectations will not be the same either. However, it requires a component that contradicts traditional management behavior as well as financial expectations. Therefore, somebody high enough will have to take a decision and carry it until Digital Transformation happens.

    Digitised Products need to consider both

    And so, finally, a digitise product needs to be managed with services and the tangible parts in mind. While a product is produced, a service is operated. The product will have development cycles that are much longer and the supply chain needs to be managed, while at the same time the service attached to the product needs to work to the customers expectations and evolve much different.

  • On Digitalised Product Management

    Now the family left me here for the afternoon, I have some time to exercise blogging and put down a few thoughts on my recent job. To write in a cosy environment, a lit the fireplace at the house we are staying in. The result is as favourable as you may imagine. Only the missing bear fur could add to the feeling. The role in marketing, “Product Management”, hasn’t been that cosy recently, for a few reasons, that are more related to corporate behaviour than to individual contribution.

    While I will need to avoid mentioning the actual product I am still working on, and it’s probably difficult even not to have any references, the below still tries to explain the tensions that exist in the world of traditional industry, moving towards a digitalised service business, in which tangible products get marginalised.

    The primary reason for me, an computer engineer, having spent all his life in service business and so to say “in the cloud“, to come to a marketing oriented role is to design and develop – as in business, not as in a computer programming – a connected product.  The Internet of Things, if you want to. Whereas many companies have Things already. But they want to offer smarter things, that’s why everything gets connected. Now connectivity has to offer many benefits over traditional products, but they’re not the primary value proposition the customer pays for. The customer still pays for the product. And in the market, any customer will ask for the smartest product available. Just like I wanted to light a fire. One that was good and warm, and keep my cosy. And to do so, I had to collect some pinecones, that would easily catch fire. It was bothersome, but necessary. 

    The things industry is not very familiar with service offerings. It’s actually something fundamentally different from the internet or services industry. To put it boldly, what a customer expects from a product: something solid. And what a customer expects from a service: something that is available anytime. (Like, literally, in the middle of the night!). While Things are sold physically and can be produced on stock, a service cannot be hold until the customer asks for it. Value through a service is created by making something more convenient. I’d have paid somebody to cut and carry the wood required to light a fire. But I had to do it myself, and that was  not only tiring but also heavy work. While, as a customer, the thing I’d buy is the wood, I would spend a premium for somebody to do the work. To add the service. Probably not much, but hey. The same happens for businesses.  While still everybody produces products, the more convenient products are in the customers favour, only at a small margin, though. Just to make an example, just recently Oracle, a business to a majority based on the sales of products, databases, announced to acquire Accenture, a consultancy service, to add services to it’s portfolio. Others have doubts this merger makes sense, exactly for the above reason. Margin driven things companies will have a difficult time appreciating low margin service as part of their portfolio.

    Just like me. I wanted to sit in front of a warm fire when spending my time without the family. It’s very clear I’d need pinecones and wood to get that, and I’d pay for it. However, if some other guy selling wood sells cut wood and carries it to my house for a fee, I’d probably appreciate that more convenient offer. But that decision has to be made very conscious, and people responsible for the service in that organisation can’t be measured on financial goals as their product colleagues, but customer satisfaction.

     

     

     

  • Celery Worker wide configuration

    Celery is a distributed task execution environment for Python. While the emphasis is on distributed in this software, the concept of having workers allows for settings beyond the individual task. While the first rule of optimisation is “don’t”, sharing database connections is a low hanging fruit in most cases. And this can be configured per worker with Celery provided signals. To create a database connection for individual worker instances, leverage these signals to create the connection when the worker starts.

    This can be achieved leveraging the worker_process_init signal, and the corresponding worker_process_shutdown signal to clean up when the worker shuts down.

    The code should obviously be picked up at worker start, hence the tasks.py file will be a good location to keep these settings.

    Example tasks.py:

    from celery.signals import worker_process_init
from celery.signals import worker_process_shutdown

app = Celery('tasks', broker=CELERY_BROKER_URL)
db = None

@worker_process_init.connect
def init_worker(**kwargs):
  global db
  log.debug('Initializing database connection for worker.')
  db = sqlite3.connect("urls.sqlite")

@worker_process_shutdown.connect
def shutdown_worker(**kwargs):
  global db
  if db:
    log.debug('Closing database connectionn for worker.')
    db.close()

    The example above opens a connection to a sqlite3 database, which in itself has other issues, but is only meant as an example. This connection is established for each individual worker at startup.

  • Google Pushes Encrypted Email System Out Into the World | On the Wire

    https://www.onthewire.io/google-pushes-encrypted-gmail-system-out-into-the-world/

  • Digitalisierung – Die den Code der Welt von morgen schreiben

    Welche Verantwortung tragen Softwareentwickler für die gesellschaftlichen Veränderungen, die sie vorantreiben? Die Antwort ist komplexer, als es der Mythos vom Programmierer als Rockstar erscheinen lässt.

    Auch die Süddeutsche greift das Thema der moralischen Verantwortung von Programmierern auf. Teil des Problems ist, dass die Profession – der Wahrnehmung des Authors nach jedenfalls – als rein technische Tätigkeit wahrgenommen wird. Vergleichbar des Berufs eines Maurers und weniger der eines Architekten oder Bauingenieurs.

    Tatsächlich versetzt die Digitalisierung aber jeden in die Position, mit äusserst abstrahierten Programmiersprachen, die teilweise mehr schon menschlicher Sprache ähneln, einen Beitrag zur weiteren Digitalisierung zu leisten. Webservices oder Chatbots zu programmieren ist mit detaillierten Anleitungen einfach zu erlernen und Schritt für Schritt auch dem Laien nachvollziehbar. Viele der zu Betrieb notwendigen Services sind kostenfrei erhältlich.

    Es gibt gewissermaßen keine Einstiegs-Hürde. Weder in der Ausbildung noch finanziell. Diese technische Ermächtigung der Gesellschaft und die Lücke in der Wahrnehmung ist zu einem erheblichen Teil auch der Demographie geschuldet, so finden sich unter Digital Natives kaum über 40-Jährige.  Genauso wie sich unter Konzernlenkern kaum unter 40-Jährige finden.

    Und so ist die Tätigkeit des Programmierens nicht länger dem Programmierer – mit einem Diplom von 1995 – vorbehalten, sondern in der Breite der Gesellschaft angekommen. Phänomene wie 4Chan oder Anonymous entstehen aus dieser technischen Möglichkeit, entkoppelt von moralischen Richtlinien. Dort werden Beiträge erzeugt, die tatsächlich ethische und moralische Fragestellungen aufwerfen.

    Es werden nicht Regeln von heute sein, die das Zusammenspiel der Gesellschaft in Zukunft regelt, die kommende Generation wird im Internet neue Regeln für den Umgang miteinander finden.

    Source: Digitalisierung – Die den Code der Welt von morgen schreiben