(Title stolen from the C2 wiki)
I just spent a few days working on a new interface for an existing system, where the new way of doing things has the interface specification being written up one of the architects, and supposedly discussed by all the stakeholders. Of course, the usual story unfolds - there is not enough time to get everyone together in a meeting, so the interface gets put together as the architect's best guess on functionality.
But the architect, by definition, is not the expert in the details of the system interface, so I've had to spend time extracting unneeded data from inputs, and providing dummy data for useless outputs. And the architect does not have the time to update the specification to include these changes.
In my opinion, it would be better for the details to be handled by the people close to them, and have the architects handle just the broad strokes. But this runs up against the custom of the higher-level abstraction people having more status, and therefore more power, with the usual empire-building and ego-stroking that accumulates over time.
Developing software in the Real World is different from all the theory. I'll attempt to explain my insights into this process, based on 25+ years in the industry in a number of different companies.
Thursday, July 30, 2015
Tuesday, July 21, 2015
Lunch Epiphanies (with apologies to the movie)
I ate lunch alone today. It's somewhat rare during the week, as I have cow-orkers with whom I have lunch pretty much every day, and when they are not able to go, I typically grab some fast food and eat in my car, listening to the radio. But it's summertime, and too damned hot to eat in the car.
In any case, I was sitting in the restaurant alone, and got a serious case of either burnout or an existential crisis. I just did not want to go back to the office. And this is after one of the better weeks I've had, actually being able to spend time writing code and learning the newer IDE and project organization.
It is really not a good feeling. And The Job is not making it easier with their continual Kool-aid vending.
In any case, I was sitting in the restaurant alone, and got a serious case of either burnout or an existential crisis. I just did not want to go back to the office. And this is after one of the better weeks I've had, actually being able to spend time writing code and learning the newer IDE and project organization.
It is really not a good feeling. And The Job is not making it easier with their continual Kool-aid vending.
Wednesday, July 15, 2015
Fighting the Good Fight
It's actually been a good week for me - I've spent most of it actually writing code.
The big thing that I did was spend 30 minutes arguing with a project lead about our new API. We are putting a REST interface over an older one, and I was arguing that we needed to make the REST one better than the older one.
It does nobody any favors to do a dumb port of one interface to another. Each type of API has strengths and weaknesses, and they rarely overlap. So I was strongly advocating that we eliminate the useless artifacts required by the older API.
The part that was unsettling was that the project lead was not mentioning any reasons for shortchanging the port. I have often had a manager tell me that there was not enough time to do something differently, and in some cases that is a valid concern. But that did not come up in this discussion, which worries me.
The big thing that I did was spend 30 minutes arguing with a project lead about our new API. We are putting a REST interface over an older one, and I was arguing that we needed to make the REST one better than the older one.
It does nobody any favors to do a dumb port of one interface to another. Each type of API has strengths and weaknesses, and they rarely overlap. So I was strongly advocating that we eliminate the useless artifacts required by the older API.
The part that was unsettling was that the project lead was not mentioning any reasons for shortchanging the port. I have often had a manager tell me that there was not enough time to do something differently, and in some cases that is a valid concern. But that did not come up in this discussion, which worries me.
Tuesday, July 07, 2015
Just a small clarification on the blog
Not that I think the readers need to be told, but just in case.....
My nom de plume "Dixie Software Ninja" is not in any way related to the current (2015) controversy over the use of the flag of the Army of Northern Virginia. I use it solely as the geographic term describing the Deep South (southeastern USA), where I currently live.
(And it's my 200th post! Yay me!)
My nom de plume "Dixie Software Ninja" is not in any way related to the current (2015) controversy over the use of the flag of the Army of Northern Virginia. I use it solely as the geographic term describing the Deep South (southeastern USA), where I currently live.
(And it's my 200th post! Yay me!)
Monday, June 08, 2015
Reach out and touch someone....
I now know why Agile recommends that the entire scrum team, if not the entire development team, be co-located.
So you can walk over to the desk of the programmer who wrote code that accesses a database row, loads in all 8 columns from the DB layer into local variables, AND DOES NOT SET THE OBJECT FIELDS FOR THE LAST 5 COLUMNS OF THE ROW, and slap them upside the head.
Or so you can look over the cube wall at the programmer who was tasked with writing a C SDK so your existing applications can perform one operation to get some data into your Java ecosystem, AND FAILS TO SET HALF THE VALUES ACROSS THE INTERFACE, and dump your coffee in their lap.
Seriously, The Job has led me to believe that the offshore teams are just interested in meeting the most minimal definition of the problem they can to get past something they think is no longer a useful part of the new, cool system.
So you can walk over to the desk of the programmer who wrote code that accesses a database row, loads in all 8 columns from the DB layer into local variables, AND DOES NOT SET THE OBJECT FIELDS FOR THE LAST 5 COLUMNS OF THE ROW, and slap them upside the head.
Or so you can look over the cube wall at the programmer who was tasked with writing a C SDK so your existing applications can perform one operation to get some data into your Java ecosystem, AND FAILS TO SET HALF THE VALUES ACROSS THE INTERFACE, and dump your coffee in their lap.
Seriously, The Job has led me to believe that the offshore teams are just interested in meeting the most minimal definition of the problem they can to get past something they think is no longer a useful part of the new, cool system.
Saturday, April 11, 2015
IDEs and doing it all by hand
Recently I've moved to new project the The Job, and into the 21st century with respect to development environments - Eclipse, Subversion, Maven, But as I am learning the ropes for this new stuff, I'm finding a curious lack in what is considered state-of-the-art. There does not seem to be any way to collect a set of actions into a bundle for repeated use - no scripting.
I'll wager I could write a set of scripts that would give me all the necessary functionality that Eclipse is providing, AND be scriptable so I could build on it as I needed
I'll wager I could write a set of scripts that would give me all the necessary functionality that Eclipse is providing, AND be scriptable so I could build on it as I needed
Tuesday, March 31, 2015
Giving a little Notice back
Not too much going on that I am able to post about at the moment, but I wanted to share out a little notice - I found out that Dustin's blog mentioned my post on developer passion and its pitfalls not long after I wrote it. SO let's give a hearty "Hello!" to Dustin,everyone!
Subscribe to:
Posts (Atom)