HN user
Find me on https://www.wittenburg.co.uk
My website started as html in 1995, vanilla html, not even css or Javascript. It has evolved to accommodate stats, and at some point (whenever it was that it was first released) I created an ASP template to manage headers, footers, contacts.
Used to update things whenever a new ASP version was released, but haven't bothered for years.
Process is simple - copy ASP template, rename, fill in the content, FTP to hosting Co and done.
I'm somewhat surprised that strategy is only mentioned once (at time of writing). Strategy is vital for any leadership role. Sun Tsu is a classic, but can be difficult to assimilate. There are many resources on Wikipedia.
Often overlooked is dealing with power and politics (https://www.wittenburg.co.uk/Work/Politics.aspx)
Keeping up to date on tech also important, especially at the tech lead/architecture level (https://www.wittenburg.co.uk/Work/Mentoring.aspx).
Linux is not an option for me. I think I've heard the "just move to Linix" thing more often than I've brushed my teeth.
I'm staying with Windows both because I've been using Microsoft's tech since MS-Dos 2 back in 1985, and work is a Microsoft estate, again making Linux a no-go for me.
That said, I have Windows 11 on my Surface, and usability stinks to high heaven, squared. And so I will stick with Windows 10. I'm keeping an eye on 11 via the Surface, but not hoping for usability to get easier in the near future...
Admittedly I'm a greybeard. Wrote my first app in 1984. Moved through the ranks, from support to dev roles, application architecture, enterprise architecture and finially process optimisation.
And so wow, those diagrams in the links - how does one even manage all those boxes?!?
Architecture is easier than coding, if you stay away from more/bigger/but_my_app_is_a_special_little_snowflake mantras. Consider the age-old, tried, tested, proven architecture models of yore (other than their most excellent diagram notations, stay away from UML).
Architecture (design) is layered, not spaghetti thrown at a wall, hoping something sticks. Most (99.9%) software domains can be divided into three horizontal layers -
1. UI
2. Application/business layer
3. Data layer
(note that both internal and external service layers sit at the same level as data layers, allowing them to be called from the application layer)
Finally, there are vertical layers (shared across the initial three layers) These typically include -
4. Communication
5. Exception management
6. Security
7. Logs
Start with that as an overview/index of the entire solution, and when the beast needs to grow, just grow it. But grow it wisely. Use the standard 3-tiered architecture model. Re-use those cross-cutting concens in new applications.
Federate identities. Standardise access/permissions management.
Finally, don't feel compelled to use all the things - if the solution is services-based, don't code a UI for it. Simply connect your client to the relevant, existing service. Yes, services can be tiered, assuming your management processes are mature.
As to the management issue. Governance is what keeps your estate from turning into a hairball. Make extensive and judicious use of
1. Risk management
2. Change management
3. Stakeholder management
4. Design reviews
5. Project review (where team members grade managers)
Establish a technical design authority. The TDA concerns itself with broadly technical matters that facilitate a system-wide perspective. This might include -
1. Systems and solutions
2. Data
3. Communications
4. Quality objectives, including security
5. Development and development operations (devops)
6. Infrastructure (including but not limited to directories; networks; servers, both on-site and remote/in clouds; workstations and mobile devices).
7. Testing (Tools, techniques, platforms, languages and frameworks)
8. Locations
> You’re not an expert in your field, otherwise you wouldn’t be publishing in a blog, but writing papers and giving interviews.
So there is no need for teachers and textbook authors, because they don't advance state of the art?
This. I have a web site that in places you might call a blog. It's got a section for work stuff, some photos, hobbies, and random pages like explaining how to drive off-road. Those off-road pages (specifically this single page - https://www.wittenburg.co.uk/offroading/Concepts/Gearing.htm...) gets more hits than all the other pages combined. I wrote it in 1998.
GDS did a great job building gov.uk, but everythig else they touched was an abject disaster. From the Diabetes project at the NHS, the fiasco that was the Office of the Public Guardian, the even bigger fiasco that happened at Border Force, the NHS, DWP...
Sure, when they were building web sites they delivered stellar stuff. Agile, break things and all that. But when you had real complexity they just... couldn't...
The Government Gateway is a prime example - single citizen login for ALL government services. It ran well, super robust and mature enough to have ironed out virtually all issues.
Then GDS decided that because the Government Gateway was based on a Microsoft stack, it needed to be re-done. The tech lead didn't understand the concept of Identity Federation, let alone SAML tokens, and that you just! can't! do secure code using agile (2-week sprint no good for meaningful security testing...).
I spent two long years at GDS banging my head against a wall. And then I left. And unsurprisingly the Microsoft-based Government gateway was never replaced, still going strong.
Always had a thing for radio control, so eventually in 2015 or so I had a look online and discovered crawlers (1:10 scale replicas of 4x4/AWD/rock crawlers). There are quite a number available to purchase in ready to run form, and self-build kits.
Lost interest in the geeky side of mechanics and electronics - they're neccessary to buy, or make a body. Jeeps, Land Rovers and Toyotas seem to be favourites.
The thing I love about it is two-fold - first is building unique bodies never done before, using styrene. Second are the events, where you meet other RC geeks, see everyone else's builds, take part in comptetions (individual and team events). In France there's an annual event that runs a pretty sweet Camel Trophy event. SuperScale in Germany is amazing for having the longest 1:10 scale bridge seen in the hoppy. USTE (Ultimate Scale Truck Expo) in Florida USA holds the largest scale RC event I've attended/know of.
Axial Fest in the US is also a big deal in the calendar, but I've never been. They have a "float you rig" challenge which got me building rafts for my trucks. Herds of fun.
Some of my trucks and build progression at https://www.wittenburg.co.uk/Play/RcTrucks.aspx
I also get a kick out of building houses/bridges/and so on for events - some of those are here - https://www.wittenburg.co.uk/Play/RcBuildings.aspx
My most ambitious build took 5 years to (almost) complete - https://www.wittenburg.co.uk/Play/FordF5Coe.aspx
Thanks I didn't know that. Happily the only ASP.NET I work with is my website, which will stay with the stack I have until/unless my ISP demands an upgrade. Although being a literal greybeard I'll probably do the lazy thing and find an ISP that does support my tech. Latest and greatest is no longer a priority.
Thanks for the update. It's a timesaver.
Top comment here is how many I interact with react when they discover my love of VB. net. Some food for thought, then:
I wrote my first complete computer program in 1986. Since then I've programmed (or scripted) in Assembler, BASIC, C, C#, C++, COBOL, F#, HTML, Java, JavaScript, LOGO, Pascal, SQL, VBA and XAML. I don't mind C#. Or Java. The majority of the code I've written in my career was written in C#. And yet my preference remains VB.NET because -
VB.NET supports both static and dynamic typing.
VB.NET is a functional language, supporting local type inference, anonymous functions, monads, and language integrated comonads (even Lisp can be more complex and verbose than VB.NET with LINQ).
VB.NET does project-wide namespace imports. C# doesn't.
VB.NET is no more or less verbose than C#. Haskell and F# however, are indeed a lot less verbose.
There are also readability issues in Java and C# that VB.NET doesn't have (braces, == and =, ! instead of Not, seperate keywords for inheritance and interface implementation, and so on). I learnt Pascal before learning C (and prefer Pascal to C). The fact that Pascal and VB.NET share syntactical smilarities (type declarations follow variable and function names, the Not keyword) is probably not an insignificant factor.
Lastly, Microsoft announced that evolution of the VB.NET language has concluded, (although it will support .Net 5). This is welcome because it makes things predictable -- modernising legacy codebases takes ages.
Well, apparently the story was conceived by a German, in which case the social system would catch him, provide the health care he needs, and when recovered he'd be back on that beach...
This started out as a password mangager. It evolved into a graph database coff after reading Linked - How Everything is Connected to Everything Else
https://www.wittenburg.co.uk/Work/Interact/History.aspx
Still under development...
Disagree 50%. Before you write any code (Corp World) you need a few diagrams detailing what and how you're going to build a thing. These lead to discussions and are refined/evolve into something you can start coding up.
Exanples -
https://www.wittenburg.co.uk/Work/Protection_System.aspx (insurance), and
https://www.wittenburg.co.uk/Work/payment_System_1.aspx (payments)
I struggle understanding cloud-based storage on anything personally mine. I want my music where I am. Same for video, and ESPECIALLY documents. Still using Windows Media Player, too.
I've been doing architecture since 2003 and I've written down the things I do regularly as an architect -
I have a home-baked system like this, mostly just files in folders and in some cases HTML-based indexes. It's not perfect and nowhere near as usable as Recall looks, but it works for me nonetheless.
I won't use Recall. It's just another Web app, and thus subject to the whims of the owners (selling my data, injecting ads when other sources of income fail, etc). I would be much more amenable to a desktop app I have absolute control over. They keep my data (assuming I were to use Recall) on their servers - but no comments I found talk about data protection or what happens to my online data if they fail, sell or merge with another company.
These days if I don't get absolute control of my data it's just not going to happen.
A model I would be happy with is a desktop app that syncs with a mobile app, encrypts everything, and is purchasable with a one-time payment.
I'm tired of Internet-everything. It always ends in disappointment for me.
Well put. He's my 2nd favourite composer, behind Dvorak. Also this excerpt from the article made me smile - "which makes one regret that Rachmaninoff neglected chamber music in his maturity."
Bet if he hadn't everyone'd howl about how he should've left chamber music alone...
I've done so much work in this space that I wrote up a patern that I modify as needed. The only data-specific issues you'll encounter are the underwriting rules - each insurer has their own secret sauce that they guard very closely.
My template - https://www.wittenburg.co.uk/Work/Protection_System.aspx
Indeed so. I've been following nuclear in Germany ever since those railroad protests when they tried to transport nuclear waste from somewhere to somewhere else which I thought was crazy (the protests).
The part I felt had merit is that none of Europe's lofty solutions to safely storing/disposing of the waste output ever came to anything. I believe until this day that industry is still trying to work out how to dig 30km down to safely store the waste underground.
That said I haven't kept up to date on any progress or better solutions.
These are technical controls - are you sure they're the right ones for your organisation - - or even needed? Organisations that comply with the GDPR typically employ a data protection officer - the person responsible for creating or overseeing the creation and ongoing maintenance of a privacy impact assessment. That feeds into requirements long before any code is written, let alone implementing other procedural or technical controls.
I was in that self same queue and also made it through surprisingly quick, only for my flight to Frankfurt being cancelled. Back at LHR now for round two.
I note that many blog on their personal web site. I decided against that back in the early 2000's, when it got popular - I just didn't want to face not having a clue what to write about next. The site's always been hosted with a commercial hosing provider. I've travelled a bit, and that meant my site could live on even if I moved yet again.
So I just use it to write down stuff I thought inetresting. I add new stuff very occasionally, and refer to it often, to this day. It's expanded (and sometimes contracted) with non-work stuff (hobbies, photos for the overseas family - although I could do more on that front).
And so I have no real expectation of myself to continually provide new content, or keep up with the latest hosting software and [at home] infrastructure. It receives lots of traffic for the 4x4 guide I wrote in 1998, and the consulting reference pages. I don't care for the traffic, but glad people find it useful. As long as it remains useful to me I'll keep it going, and call it a success.
I use Windows Explorer. Simple folder names like work, with subfolders for employers. Another folder for car, identity, one for medical, another for my son with subfolders for reports, pictures he drew, etc.
I can find anything very quickly. When search fails me because I forgot a vendor name or something, I just navigate the folders.
No software required other than what comes with Windows.
They were ideas of the top of my head. And what if he/she DOES enjoy that aspect? I'm a snowboarder and love it. The point is to have an open mind. Like it? Great. If not, also great, no?
The caveat, I think, is that what he describes is quintessentially American. I'm pretty well travelled and have only seen such overt and absolute polarisation in the US. I'm sure there are others but I haven't seen it in Europe, Africa or the far East. It's quite the source of amusement in my circles.
I say this knowing Elon is (was?) South African.
With things like (marathon) running, hiking, it is easy to meassure Objective progress and qutie hard to moneteize.
Well, no. You can do sooo much here. Log your hike, provide coordinates of off-the-beaten-track routes and sites, provide info on trail conditions, run team events, gear reviews, first aid courses...
Also, who said I can't be the next Rembrandt? Kandinsky is only one of many proofs that that second sentence of yours is off the mark.
I've actually just started work on making piste maps better for snowboarders. Making bank off that would be ace, if not well OK then. Being defeatist because the probability of failure is bigger than success is defeatist, no?
Move as far away as possible is about all I can think of. Punta Arens, Cape Town (my first option), maybe Christchurch or Dunedin...
Requirements are easy, people are not. It's great talking about user stories and use cases and rapid prototyping - but how do you know you have the RIGHT use cases and user stories...?
What follows is one way to get requierments right -
¹ Current State
Assess the situation. Understand the transformation (one or more processes) the client seeks to address, and find out what the technology landscape looks like. Start identifying stakeholders, and familiarise yourself with the client's worldview, environment, and the power and political landscape.
² Objective
Identify who the client is, and define the client's objective. The objective is specific, measurable, agreed to by the client,realistic, and time-boxed. It is guided by the results of the situational analysis.
³ Scope
Bound the solution by outlining it's features and functions, by defining what's out of scope, and by discussing the criteria by which success is measured. The scope delineates what stakeholders expect the project to deliver.
It's not hard but it's not going to fall into your lap without a little effort.
¹ https://www.wittenburg.co.uk/Work/Transformation.aspx
² https://www.wittenburg.co.uk/Work/Objectives.aspx
³ https://www.wittenburg.co.uk/Work/Scope.aspx
(Being nice helps too - people like helping nice people -- https://www.wittenburg.co.uk/Work/Trust.aspx)
It's relevant because your GP asked specifically whether I was talking about network design.
Messaging middleware such as queues is mostly redundant. Simplistically -
Client --
If you cache a new submission (message) locally before submitting, you just keep re-submitting until the server returns an ACK for that submission; and your local cache is empty.
Scale clients out as needed.
Server --
If a message is received in good order, return an ACK.
If a message is a duplicate, discard the message and return an ACK.
If a message can only be received once, discard if it already exists on the server, and return an ACK.
If a message is invalid, return a FAIL.
Scale hardware out or up, as needed (ref. "capacity, item 2 in the linked blog post above). Scale queues out by adding service endpoints on the server. Async/await makes the client experience painless. You save your employer $$ because no additional procurement contracts, no licensing fees, no additional server-side infrastructure to run queues, and no consultancy fees to set up and operate Rabbit MQ/Tibco/IBM MQ/Amazon SQS/Azure Queue Storage or whatever other queueing solution the org uses.
Message passing includes concepts auch as durability, security policies, message filtering,delivery policies, routing policies, batching, and so on. The above can support all of that and, if your scenario calls for it, none of it.
The financial argument reduces to dev time vs. procurement, deployment and operational costs of whatever 3rd party product is used, as well as integration, of course.
* I note and welcome the downvotes. However I'd love it more if you'd present a coherent counter argument with your vote.