Archive

Technical

Technical Practices Are Worthless Without Social Foundations

December 26, 2024
Article, Collaboration, Culture change, Product development, Quintessence, Social engineering, Software development, Technical
Leave a comment

Technical Practices Are Worthless Without Social Foundations

The Missing Social Layer

What happens when an organisation adopts the latest technical practices without considering its social environment? Why do we endlessly see promising technical initiatives falter, even with substantial investment and genuine commitment? Could the answer lie not in the practices themselves, but in the underlying social fabric of our workplaces?

Common Social Barriers

Fear of Failure

When was the last time you saw a team hesitate to deploy, despite having robust automated testing? What made them pause? Could it have been the memory of that last team meeting where someone was publicly criticised for a production issue?

Silos and Territory Wars

How effective is your beautifully designed microservice architecture when teams refuse to collaborate? What value does elegant API design bring when knowledge is hoarded rather than shared? Haven’t we all watched teams dodge responsibility with “that’s not our problem”?

Management Monstrosities

Why do managers often resist investment in refactoring or comprehensive test suites? Could it stem from a fundamental category error—treating software development as if it were manufacturing or construction or service rather than collaborative knowledge work? How do inappropriate metrics and misaligned incentives contribute to this dysfunction?

The Oh So Rare Success Stories

In organisations where technical practices flourish, what sets them apart? Could it be their:

  • Culture of open communication and trust?
  • Folks of all stripes who genuinely understand and support technical practices?
  • Active encouragement of CKW perspectives like non-linear value creation (outcomes do not correlate with effort), that learning is delivery (we can’t separate discovery from doing), and inherent synergistism (the whole > the sum of parts)?
  • Treatment of failures as learning opportunities?

Moving Forward

Before diving into technical transformations, organisations might choose to first examine:

  1. How do teams currently interact and communicate?
  2. What prevents honest dialogue about problems?
  3. Do folks truly understand the nature of software development i.e. it’s CKW?
  4. What stands in the way of learning from failures?

Conclusion

Could it be that most organisations aren’t ready for advanced technical practices, not due to technical capability, but because of their social environment? What would need to change in your organisation for these practices to take root, let alone truly thrive?

When you look at your next technical practices initiative, perhaps the real question isn’t whether your team can implement it—but whether your organisation provides the social foundation for it to flourish?

Using Svelte with CherryPy

July 25, 2023
Article, Technical
Leave a comment

Using Svelte with CherryPy

I’ve been using CherryPyfor decades. And along comes Svelte…

Using Svelte with CherryPy is like combining any frontend framework with a backend framework. In this setup, Svelte is responsible for building the client-side user interface, while CherryPy is used for server-side processing, handling HTTP requests, and communicating with databases. Here’s a simple guide on how you might use these two together:

  1. Separate Frontend and Backend Development: Generally, it’s a good idea to keep your frontend (Svelte) and backend (CherryPy) code separate. This makes it easier to manage both parts of your project.
  2. API Design: Design your server-side endpoints in CherryPy. These endpoints should correspond to the different types of data your client might request. For example, if you have a blog, you might have endpoints to get all posts, get a single post, create a post, update a post, and delete a post. This is often done using REST or GraphQL.
  3. Server-Side Logic: Implement the server-side logic in CherryPy. This involves processing requests, handling business logic, and communicating with databases.
  4. Fetch API in Svelte: In your Svelte application, you can use the Fetch API to make HTTP requests to your CherryPy backend. This can be done directly in your Svelte components. Svelte’s reactivity features make it easy to update the UI when data changes.
  5. Websockets: If your application needs real-time updates, you could use websockets. Both Svelte and CherryPy have support for this.
  6. Build & Deployment: When you’re ready to deploy your app, you’ll need to compile your Svelte app to JavaScript, HTML, and CSS. These static files can then be served by CherryPy or any static file server. On the server side, you’ll need to deploy your CherryPy app to a server that supports Python.

Remember, both Svelte and CherryPy are flexible and can support a variety of architectures, so you may need to adjust this setup based on the needs of your project. Additionally, when developing applications, it’s important to consider factors like error handling, data validation, security, and performance optimization.

Why is True Fellowship So Rare, Especially in Tech?

May 3, 2023
Alien tech, Article, Collaboration, Culture change, Fellowship, Organisational effectiveness, Software development, Teambuilding, Technical
Leave a comment

Why is True Fellowship So Rare, Especially in Tech?

Why is fellowship in organisations, particularly in tech companies, such a rare phenomenon, and yet when it does emerge, it’s immensely powerful? What are the factors that make it so elusive, and conversely, the elements that make it thrive when it does manifest?

In the world of technology, competition and individualism often take centre stage, overshadowing the potential benefits of collaboration and fellowship. Could it be that the pressure to innovate, coupled with the race to stay ahead of the curve, pushes people to focus more on their individual achievements and personal wellbeing rather than the collective good?

There’s also the issue of diverse backgrounds and skill sets. With experts in various fields such as engineering, design, marketing, and more, it’s possible that this diversity might inadvertently create silos. Do these specialised domains lead to a lack of understanding and empathy among team members, preventing the formation of a cohesive, supportive environment?

And yet, when fellowship does take root within tech organisations, its power is undeniable. Why is that? Could it be that the amalgamation of diverse perspectives, skills, and experiences in a collaborative environment leads to breakthroughs and innovations that might otherwise be impossible? When individuals work together, for example with Ensemble Working, sharing their knowledge and challenging one another’s ideas, they pave the way for novel solutions and approaches.

Perhaps another reason for the potency of fellowship in tech companies is the sheer complexity of the problems they tackle. The adage “two heads are better than one” rings true, as the collective intelligence of a group working in harmony often surpasses that of even the brightest individual. In an environment where fellowship thrives, team members can rely on each other’s strengths, ultimately yielding better results.

So, why is fellowship so rare in tech organisations? It appears that the competitive nature of the industry, coupled with the diversity of skills and backgrounds, might pose challenges to fostering a collaborative environment. However, when such an environment does emerge, it unlocks the potential for innovation, breakthroughs, and success that are unparalleled in their impact. Thus organisations maigh choose to recognise and nurture the power of #fellowship to stay ahead in an ever-evolving commercial landscape.

Tech Solutions vs. Cultural Issues: Can Tech Fix Culture?

January 24, 2023
Article, Culture change, Technical
Leave a comment

Tech Solutions vs. Cultural Issues: Can Tech Fix Culture?

Cultural issues refer to the social and behavioral norms, assumptions, and beliefs that shape a society or group of people. These issues can range from discrimination and prejudice to cultural appropriation and misunderstanding. Technical solutions, on the other hand, refer to the use of technology and data-driven approaches to solve problems and improve efficiency.

The question of whether we can fix cultural issues with technical solutions is a complex one. On one hand, technology and data-driven approaches can be incredibly powerful tools for identifying and addressing cultural issues. For example, data analysis can be used to identify patterns of discrimination and bias in the workplace, while social media and other digital platforms can be used to promote awareness and education about cultural issues. Additionally, virtual reality and other immersive technologies can be used to simulate experiences and foster empathy, which can be a powerful tool for addressing cultural issues.

On the other hand, it is important to recognise that cultural issues are deeply rooted in societal norms, assumptions, and beliefs. They are often the result of centuries of history and are deeply ingrained in our social and cultural fabric. Therefore, simply implementing a technical solution is generally insufficient to address these issues. Instead, a more holistic approach is needed that addresses the underlying social and cultural factors that contribute to cultural issues.

Furthermore, it is essential to note that technology can be both a tool and a hindrance in addressing cultural issues. While technology can be used to promote awareness and education, it can also be used to perpetuate stereotypes and discrimination. For example, algorithms used in social media and search engines can perpetuate biases and perpetuate harmful stereotypes. Therefore, it is essential to be aware of the potential downsides of using technology to address cultural issues and take steps to mitigate these risks.

In conclusion, while technology and data-driven approaches can be powerful tools for addressing cultural issues, it is important to recognise that these issues are deeply rooted in societal norms, assumptions, and beliefs. Therefore, a more holistic approach is needed that addresses the underlying social and cultural factors that contribute to these issues. Additionally, care should be taken to ensure that technology is not used to perpetuate stereotypes and discrimination. Ultimately, addressing cultural issues requires a multifaceted approach that leverages both technical solutions and social and cultural understanding.

Quickie: Love Of Coding

June 18, 2022
Alien tech, Coding, Culture change, Lamentation, NoSoftware, Organisational effectiveness, Quickies, Quintessence, Technical
1 Comment

Coding

After all these years, I still love coding (as in writing software).

It’s just that it’s tainted by the certainty that there’s so many other more effective ways of adding value and meeting folks’ needs.

Spending time coding feels so… self-indulgent.

Microservices In Embedded Systems

April 25, 2015
Technical
5 Comments

Microservices In Embedded Systems

I don’t write many “technical” posts, finding people and organisations more challenging, and hence more interesting, but this is one. If you like the diversion, let me know and I’d be happy to write some more such posts.

Some years back I was running a boutique embedded systems development company, in partnership with a hardware engineer. He’d design and build the hardware – micro-controller based – and I’d implement the core functionality in software. Mostly in C, C++ or Python, with some e.g. PIC assembler here and there. OSes were Linux, WindowsCE, or naked. Approach was entirely Agile (on both the hardware and software fronts).

We specialised in hyperconnected devices – now more widely known as the Internet of Things – so every device we designed centred around an embedded web (HTTP) server.

One particular project – at the higher end of micro-controller capabilities, with virtual memory addressing and a fairly beefy CPU – was an event logging device with e.g. remote access (dial-in or ethernet) capabilities, a touch panel for local admin, and a bunch of digital I/O lines for scanning the connected devices to be logged.

I chose Python as the prime option for the implementation, with Javascript and CSS for the touch UI, some C for low-level hardware (device driver) functions, and Json for initial device configuration a.k.a. policies.

Once I had a Python implementation that would run on the platform, I gave some thought, as I was writing some early code, to a suitable architecture. I knew the client had a vague interest in extending the range of product variants in the future, as well as possibly adding more features, so although not a priority, extensibility was at the back of my mind.

Aside: Another reason for Python being the favoured implementation language was the excellent CherryPy webserver package, which I had used often before. Unfortunately, it turned out that CherryPy wouldn’t run on the platform (WindowsCE), and tight schedules did not permit an investigation as to why. So I went with a basic SimpleHTTPServer implementation instead.

More pressing, in terms of getting the whole thing working, was the memory usage of each Python process. And the relative shortage of memory on the device (suggested by the economics of the design). This consideration was paramount, it turned out, and a good deal of the work was a consequence of shoe-horning the necessary functionality into the memory space of the device.

Eventually, the architecture evolved into circa a dozen separate, cooperating Python processes. (Note: I stuck with Python, because actually implementing the necessary functionality in Python was much quicker and less painful than doing the same in e.g. C or assembler).

In retrospect, today we might choose to call this a microservice architecture. Each Python process ran independently of the others, doing its small bit, and interacting with one or more of the other services as and when necessary.

The microservices included:

  • Watchdog
  • MCP
  • Networking
  • TimeWarden
  • MediaWarden
  • EventScanning
  • EventLogging
  • Webserver
  • RemoteCommandListener
  • SyncSource
  • DeviceStatus

Aside: Actually, there were rather more microservices than this originally, but I had to combine some in order to meet the memory constraints.

At the end of the project, it was clear (to me, not to anyone else) that, serendipitously, the architecture was such that adding new features, even whole new microservices, would be a piece of cake. I’m not aware that this was ever appreciated, let alone acted upon (no one else involved was at all software savvy).

Have you worked in embedded systems development? Have you ever seen or considered the pros (and cons) of a microservices-style architectural approach?

– Bob

Further Reading

Stop Thinking About User Interface ~ Juan José Ramírez
Windows CE: Synchronization Objects – Events ~ Bruce Eitman