Disqus - Latest Comments for phomer

Re: Why Startup Technical Diligence is a Waste of Time

Paul W. Homer — Wed, 13 Jul 2016 15:19:03 -0000

I almost agree, but I think you are missing one rather critical issue, which is analysis. You get to the right solution for a monitizable problem when you correctly and deeply analyze that problem down into a coherent mapping. That's what you build up into the product. To do so, takes the ability to abstract out the proverbial forest from the trees, which in most cases is a skill requiring a strong logical background mixed with the power to generalize. Those prerequisites are most often found on the tech side. If they don't exist, the high-level idea might be wonderful, but eventually the implementation will be lacking. That sort of structured creative visualization is actually fairly rare, so hoping that it shows up later is risky.

It's also true however that the most wonderful product in the world will absolutely fail if the business side of the equation is broken. Both, very different, sides are necessary.

Re: Software Engineering: The Next 50 Years

Paul W. Homer — Thu, 03 Sep 2015 13:42:34 -0000

I'm kinda hoping that it plays out like this:

http://theprogrammersparado...

But my real expectation is that it'll take over a hundred years to get there. At the rate we are going now, in fifty years software will have so strangled modern society that most people will revert to living in caves, just to avoid the pain :-)

Paul.

Re: Coding and Cynicism

Paul W. Homer — Wed, 10 Oct 2012 11:30:59 -0000

What happens is that younger developers start making 'assumptions' about the details. But there is a big difference between knowing and assuming. If you really dig deeply, you'll see that most systems rest on a huge number of assumptions, most of them weak. The bugs don't manifest themselves, but they are still there lurking. It's phenomenally difficult (and slow) to investigate all of the details to any precise level, and given that technology has exploded in size and complexity, it is stunning how fragile so much of our code has become. Still, anything handling a feed from an external system should validate all of the data just the same as if a person were typing it. If the data has been touched by any outside source, then it could be wrong or invalid. Another assumption, but one that makes most days a little less painful :-)

Paul.

Re: What's the Current State of Graph Databases?

Paul W. Homer — Wed, 26 Sep 2012 14:12:57 -0000

They are, I believe, equally expressible to Turing Machines. What that means is that you could quite possibly persist your internal runtime model exactly as it stands, without having to translate it into another limited expressible abstraction (and do wild and wonderful things with weak references). Great power, but it comes at the cost of possibly running straight into N^2 or better complexity, which often goes unnoticed in testing but can blow up spectacularly when applied against real data.

Paul.

Re: An unambiguous software version scheme

Paul W. Homer — Fri, 21 Sep 2012 13:33:39 -0000

That's pretty much the way I always implement versions, but I tend to think of them in terms of backward compatibility. So it's major.minor.fix. A fix is just a quick fix for a bug. A minor change remains compatibility with the previous version (and likely adds a few features). A major change means a major upgrade.

Another thing I've found that helps is to make sure that each 'piece' has its own version number. So if you've got an app that uses a relational schema, then both should have their own numbers (and they can drift). If you've built a platform for components, then each should be numbered individually. You don't need to go overboard, but it makes releasing and supporting the system far easier if you've broken it down into separately installable sub-pieces. It also reduces testing, since the impact of a change won't go beyond the sub-piece (and if it does then the breakdown is broken :-)

Paul.

Re: Am I An Outlier, Or Are Apple Products No Longer Easy To Use?

Paul W. Homer — Fri, 14 Sep 2012 13:41:20 -0000

One the glossy shine of the new gadgets wares off, everyone comes to understand what a software exec. told me a decade ago: "the dirty little secret of the software industry is that none of this stuff actually works". Welcome to knowledge :-)

Re: Why the Statement “I Don’t Source Control My Unit Tests” Makes Me Happy

Paul W. Homer — Wed, 12 Sep 2012 10:20:25 -0000

Your side comment is really (really) funny :-) Mostly because he did resemble that cranky old neighbor that is always yelling at the kids and spoiling all of the fun, but I had never really thought of it that way before. Hardware has made stunning advances and I am often amazed at a lot of the new toys (my watch is an iPod nano with 70 albums on it for my listening pleasure :-) Software is way larger and the amount of 'canned' pieces available is also stunning. But, the time it takes to get out a quality commercial product seems to have gotten longer, not shorter (guesstimate, I've never seen a stat. that actually measured this). The bugs that people put up with now are also stunning. The old stuff didn't do much, but it didn't break regularly either (this is mostly an apples to oranges comparison because the breadth of functionality was so much smaller, it clearly would be easier to get better quality out of it). From my perspective, the quality has declined, but given that everything else is 'stunning', I expected that software would follow suite. So it's not so much what we have today that worries me, but rather what we should have had instead. Instead of moving forward, we keep getting reset to zero. Things known get lost. We've reinvented the same familiar wheels over and over, but they never really build on their predecessors. They're just larger and have collections of different problems.

Re: Why the Statement “I Don’t Source Control My Unit Tests” Makes Me Happy

Paul W. Homer — Sun, 09 Sep 2012 00:23:05 -0000

You mean the pretty tiles? That's a new Blogger template. I added it a few months back. It is quite amusing, there are several different displays and I find resizing the window very entertaining. (for some reason this comment box is ignoring returns and enter, so I can't start seem to start new paragraphs. I'm back a few versions in Ubuntu and having some issues with packages, so I haven't upgraded my Firefox for a while. So I guess it's one big paragraph for me :-) From my experiences, the focus on software quality fluctuates quite a bit. A couple of decades back, some subsets of the programming community were deeply focused on 'taking the extra time to get it right'. The types of bugs we see commonly in programs today were unforgivable. That changed significantly during the dot-com period as software exploded into the main stream and everybody was anxious to cash in. Still, it all seems to go right back to the sixties when they coined the term 'software crisis' to highlight how much less effort programmers were putting into their work. In the eighties I had a prof that loved to say that it all went to hell the moment we got 'interactive editors'. He felt that it was only through the slow painful experience of working with punch cards that people tended towards real economy of expression and self discipline :-) What seems to happen is that the core issues get reset with each new wave of programmers. At first it is about just pounding out the code as fast as possible. Then it becomes all about quality, then finally scale. But by then the older waves have mostly left the field, and the kids go right back to pounding again. We're an industry that has forgotten most of what we used to know, sort of like the character of Lucy in 50 First Dates.

Re: Why the Statement “I Don’t Source Control My Unit Tests” Makes Me Happy

Paul W. Homer — Sat, 08 Sep 2012 11:03:23 -0000

Unit tests for something complex like a parser are a definite necessity. But I've always felt that unit tests on more mundane code that also must be tested at the system level, is redundant. A lot of code is just glue or the required noise to get the whole thing working. One big thing I've found over the years is that 'reuse' heavily cuts down on testing effort. If the system is built with tonnes of redundant 'brute forced' code, then the little inconsistencies require way more testing or the system is fragile and unstable. If the underlying code is well-structured and there is very little repetition, then testing one part of the system can often prove that many other parts are OK as well. For instance, if it's a web app and all of the communication to and from the server go through the same library, using the same basic features, then getting any screen to work means they all will. If, on the other hand, each screen talks to the server in its own unique way, then all screens need to be tested (pretty much every time if there is no reuse underneath). In general I've found that most projects are under-resourced, so the biggest issue in development is in trying to do the least amount of work possible, while still keeping the quality in an acceptable range.

Re: Why the Statement “I Don’t Source Control My Unit Tests” Makes Me Happy

Paul W. Homer — Fri, 07 Sep 2012 18:03:52 -0000

Testing is definitely important, but unit tests are often too fine-grained to catch the really significant (and costly) system-wide problems that plague most development. TDD proscribes a hyper-active approach to testing, resulting in significantly more initial effort and a considerable bloat to the test base. Some tests should certainly stay around, but some are just scaffolding and once they've shown an absence of problems they become unnecessary baggage. They can also provide a dangerous false confidence for practices like refactoring. A test is nothing more than a different way of stating a problem, if both the code and the test are wrong what does it buy you?

That being said, your friend should stuff it into source code control anyways. Later it is easier to refactor, then to start over ...

Paul.

Re: The Senior Position Fallacy - Diary Of A Ninja

Paul W. Homer — Thu, 06 Sep 2012 16:04:21 -0000

I've moved into split positions that are essentially lead-technical (architecture, coding + product management) and management. However, it is very hard to find these types of dual positions and they always come at a huge cost. Often there is some non-technical person encroaching on the management side because they assume you can't handle both sides at the same time. Occasionally some of the underlying techs don't like it either (they think you're too businessy). So it can be a rather frustrating balancing act.

Perhaps it just better to step away and leave coding as a hobby ...

Paul.

Re: "The Best Programming Advice I Ever Got" with Russ Olsen

Paul W. Homer — Sun, 02 Sep 2012 09:50:47 -0000

Of course you have to be careful the new code is really as good as you think it is.

Way way back I wrote a resource manager in C for a huge project. To avoid deadlocks I implemented a standard paradigm where all of the resources have a precedence, you have to take A before B for instance. We had a junior programmer whose was working on some new code and she ran into a problem because she wanted to get B first. Without talking to us, she went off and copied all of the resource management code, but reversed the order, so now she could grab B, then A. Then she went off and tested it for her process and found that it worked quite well. She then checked in her code and the second, modified resource manager.

When I saw the changes I rolled them all back. I went to her to explain that if we ran her code in production, it would cause a deadlock every once in a while, and crash everything. She wasn't familiar with any of the resource contention issues/algorithms and insisted that I was wrong because she had tested her process on her machine and it worked. I really tried to get the concept across to her that in production there are dozens of processes and the point of the resource manager was to prevent conflicts between them but she didn't want to hear it. No doubt she still thinks that we were just being over protective of our code.

Sometimes the new code is better, but sometimes it just appears that way because it skips over a significant part of the problem. What should matter is whether it works 'correctly' and solves everything, not who wrote it.

Paul.

Re: "The Best Programming Advice I Ever Got" with Russ Olsen

Paul W. Homer — Fri, 10 Aug 2012 11:01:00 -0000

I've definitely seen that type of attitude too much. The counter-measure is to make sure that no code is 'other people's code', and thus there is no good reason to stay out of it. Of course, that comes from a group of people cooperating to build great things, rather than a group of people competing against each other (which, sadly, is too often the case).

Paul.

Re: Open source won

Paul W. Homer — Mon, 30 Jul 2012 18:42:51 -0000

A couple of decades back, when I was in school, I worked with this older coder who had set up his own 1-man shop. He wrote nice, but not particularly exotic stuff which was distributed and supported by a third party. It provided a good living and allowed for him to get involved in many interests outside of paying the rent. It allowed him to experiment, without the constant pressure to hustle.

That "luxury" probably still exists in some corners of our industry, but it is fading. We are more often forced to write what we have to, then to write what we want to. It might be fine when you are young to give it away for free, but unless you are born wealthy, you eventually acquire dependencies that need revenue. And so the freedom to experiment, to improve, to try things gives way to the hustle to pay the bills. And the experiments that we really need to achieve new growth are those that depend on significant knowledge and experience, otherwise they tend to be pale re-writes of low hanging fruit.

We've lost because we've been reduced to code monkeys or we just bail to other professions once we've figured out the game.

Paul.

Re: Open source won

Paul W. Homer — Mon, 30 Jul 2012 12:50:16 -0000

Open Source my have won, but professional programmers lost. With an expectation that almost everything but the last minute 'glue' code should be given away for free it's becoming significantly harder to find actual paying jobs that aren't excruciatingly mind-numbing. Sure there are a few well paid Open Source coders and some good positions in the mega-companies but for most of the rest, it is less wages to deal with larger volumes of buggier code and no real avenue left to get problems properly fixed. We've lowered the value of coding so far that Instead of getting opportunities to build better systems we're left cobbling together bigger messes in worse time constraints. If we value our own efforts so poorly, then it is no surprise that others do too. I'm not planning on celebrating anytime soon ...

Paul.

Re: The Programmer's Paradox: Software Clearing Houses

Paul W. Homer — Tue, 22 May 2012 14:52:07 -0000

Yes, I think the coders should own the rights to their own work, but not have to be tied down by the business of making money.

Re: CodeGrunt - The Brittleness of Type Hierarchies

Paul W. Homer — Wed, 09 May 2012 18:30:17 -0000

Your approach definitely affects the cost of your mistakes. In the most general sense, you can produce things that are essentially 'static' a whole lot faster than things that are 'dynamic', but again it's another trade-off. If your static code is wrong, you scrap it and redo it. If you've made it highly dynamic, yes it has taken significantly longer, but if you got it right, the change is minimized (you win when it's just one line).

It's worth noting that you are also crossing over another trade-off. The more static you make things, the more you can leverage the computer to tell you that it is incorrect. The more dynamic you make it, the harder it is to detect and fix problems. The two trade-offs crash nastily in the middle somewhere.

The approach I use is to go very abstract when I've analyzed that I can't pin down the right answers. That is, if I ask one day and get an answer, then ask again a week later and get a different answer, I start to assume that there is no static answer, so a static solution will fail badly. If it remains unchanging over time, then assuming that it doesn't violate my architecture or reuse, the fastest thing you can type in, is probably the best thing. I do find that most abstraction and generalization take longer coming out of the gate, but always pay for themselves in the longer run. Yet another trade-off ...

But I do have one major requirement, I won't start development until I can visualize the whole solution in my head (not all of the code, but at least all of the major points/lines/data of the system). I generally work on large, complex commercial web apps these days -- usually my own designs -- so even if it isn't all on paper, to direct other resources (and complete my share of the code) I really need to know where we are going long before we try to go there (I prefer small tiger teams). Things change, of course, but if they change radically then I screwed up badly somewhere (and should start sending out my resume immediately :-)

Paul.

Re: CodeGrunt - The Brittleness of Type Hierarchies

Paul W. Homer — Wed, 09 May 2012 12:06:41 -0000

Not to get to tied up in your model, but these were problems that I encountered 2 decades ago. The domain hasn't changed significantly. ISIN's are probably not unique (some ids treat different flavors of security as different securities, some do not. The problem gets far more complex when you are dealing with a large number of different financial ids and trying to relate them to each other), but these days I have just enough experience to never make that type of assumption anyways. Things that seem simple, rarely are, so in time you learn to distinguish between the facts you know, and the things that you are just guessing at.

What it really amounts to is that you've written the *wrong* code. In this circumstance, you are correct you can a) do the right thing or b) hack it. If there are the usual time pressures 'hacking it' is always a short-term win. However, it's a trade-off, so it is also always a long-term loss.

Choosing #a is a hard choice, because it often requires a fight (with yourself or others). If you are not in control, then you may lose. Even when you are in control, sometimes to win the 'larger game', you still have to pick #b. But if you're not planning to leave the job soon, you know your choice will haunt you at some point, just not today.

Would people pick #a if it were really easy? In most IDEs there are now excellent tools to hugely reduce the amount of work. In the old days, we had to do it all by hand, it was considerably more effort. Still many people won't pick #a these days even when they have a choice. Since it requires specific intelligence relative to a larger context, #a will only ever be 'trivial' if it is done by an AI, and we currently don't know how to really built an AI yet. But of course, if you had that AI, you'd probably be out of a job, since in that case you are just the middle-man between it and the stakeholders.

Would people pick #a if the language were loosely typed? No, because that generally applies to the type of a variable, not to a structure of variables. And even in a loosely typed language, at some point the rubber has to hit the road, so there is always some code, somewhere that has to be changed because it works on the specific data. You can't avoid it, or the code is so generalized that it's just a generic Turing Machine (and does nothing unless configured, which is now where you changes lie).

So, you've written the *wrong* code, and now you need to fix it or make it worse. No tools or technology will make it trivial, it comes down to the self-discipline of the programmers involved. In that, it is one of the many factors that separate the experience professionals. Some days you just have to admit that it went wrong, and correct it before it gets worse. The longer you delay, the worse it gets. If this is a regular event, then you need to fix the problem at the source, which as I said before was the incoming requirements flow. You can't build something if you don't know what it is, and if it's changing all the time, but the domain isn't, then it isn't because the domain is dynamic that it is changing. It's because somebody is feeding the *wrong* information into the project ...

Paul.

Re: CodeGrunt - The Brittleness of Type Hierarchies

Paul W. Homer — Wed, 09 May 2012 11:13:32 -0000

Honestly, I think the problem lies with the fact that the necessary analysis wasn't done correctly, coupled with a lack of domain knowledge. Basically in your example, the programmers (and whoever is supplying the requirements) are just taking *wild* guesses and their expectations for the amount of work are totally out of whack. If you've been doing financial programming for a while, you eventually get to understand how to model the data. If you've been building systems for a while, you know that the model has to be wide enough to accommodate different security types. What you're trying to do is take a bunch of short-cuts (in both learning and thinking), but you're not willing to pay the price in refactoring that you've accumulated while doing them. You fix this by bring in experience, or accepting that you have to spend time digging yourself out of the hole you created. This type of problem exists for all languages/technologies.

Re: 7 programming myths -- busted!

Paul W. Homer — Wed, 25 Apr 2012 16:44:28 -0000

I really liked the article, except for the last point. Elegance != clever, I think that's the essence of the myth. If you take a complex problem and make the implementation simple and obvious (and it's readable), then it is elegant. If it's just clever, well... as one of my friends loved to say "Monkey's are clever".

Paul.
PS. Elegance can exist in code, but it's a very rare sight. You know you've seen it when you look at the source code and think "Oh, this problem isn't hard, I could have written this really quickly"

Re: The Programmer's Paradox: Structured Questioning

Paul W. Homer — Sun, 15 Apr 2012 23:04:44 -0000

Thanks for the reference. Leo looks very interesting, I'll have to spend some time to explore it. If you add 'clones' to a hierarchy, you get a directed acyclic graph (DAG), if you allow cycles to that you get a graph. So if the clone nodes can reference each other, then they can express a graph. Graphs are very expressive, but they are algorithmically more complex than a DAG. It's nice to see someone take on that type of challenge :-)

Paul.

Re: Language Agnostic Web Framework and Packages

Paul W. Homer — Wed, 11 Apr 2012 16:57:37 -0000

Someday, if I every get time, I was thinking of just having the coders spec the internal data model, and maybe a little bit of special presentation, and then having the code dynamically generate the screens (and the schema), so that the layout can automatically adapt to different form factors. One big screen on a web page, might render on a phone as two or three screens. That would be a nifty trick.

Paul.

Re: Language Agnostic Web Framework and Packages

Paul W. Homer — Wed, 11 Apr 2012 16:55:35 -0000

One fun thing I've been able to jam into a couple of (proprietary) frameworks is a high degree of 'reuse' enforcement. The idea is to make it easy and 'minimal' to create screens, so then the 'screen' code is nearly trivial, and all of the mechanics exist below in the framework. Way back, for many screens, everything a screen needed was around 200 lines of code. The trick is to abstract away the presentation and bind that to something like CSS. So all the user is really specifying are the main data elements. Most code can vanish into a puff of implicit handling, but if and only if that handling matches the assumptions of a reasonable coder.

I did spin it a little, and split the screen handling out from the underlying data model. The model I moved to the server (GWT does the front-end) and then used Hiberate (with a lot of fiddling) to redo the older OODB paradigms.

Paul.

Re: 4 Reasons Developers Resist Code Review (and Why They Shouldn’t)

Paul W. Homer — Tue, 27 Mar 2012 16:42:42 -0000

I'd actually say the biggest problems are time, and the fact that there is a huge variation in programming styles. Most projects start life with only a fraction of the amount of time they need, particularly the smaller ones. That's often caused by people's expectations being based on the interface, not the whole system.

As far as style goes, it's often a big problem just to get programmers to read each other's code, let alone provide positive feedback on it. As a profession, coders tend towards their own eclectic styles, which gets reinforced by the culture. That I think stems from seeing the work as being highly creative and an art form. There certainly is a lot of creative problem solving in programming, but often that energy gets applied towards poor reinventions of existing solutions, rather than building on them. Thus getting three programmers in the same will room will often result in five 'perfect solutions', none of which will match someone else's work, so the feedback degenerates (or nobody makes deep comments).

Paul.

Re: The Programmer's Paradox: Lost in Thought

Paul W. Homer — Sun, 18 Mar 2012 10:08:53 -0000

Your view is good. I tend to call product-ready stuff 'industrial quality code', but it means the same thing. A common problem for programmers is that they fixate only a small sub-piece of the overall problem and then rush to get it to work, so they essentially end up writing the 'wrong code' or miss a lot of the significant corner-cases. Sometimes they dive in too quickly, so for technical challenges like concurrency they 'sort-of' understand how it works, but 'sort-of' isn't good enough.

Way back when I was young, in the early days of the Apple II, there were all sorts of great magazine articles on 'bombproof data entry', that basically started with the acknowledgement that if you let the users type stuff in, they could type anything in. Strangely, that understanding seems to be lost on modern programmers :-)

By far the biggest challenges I see for in-experienced programmers is their need to re-invent parts of the system that already exist because they don't like reading or extending other people's work. So you get a lot of systems out there with the same basic pieces, re-written in slightly different ways that cause a wide range of avoidable problems. It's inefficient and kills the overall quality, but somehow it has become ingrained into the culture of programming (in terms like 'hacking').