The *business* of software
QOTW: What would you change about the way you write software?
If there was one thing you could change about the way you write software, what would it be? And what’s stopping you? $20 for the best answer. Post here.
Replies to This Discussion
-
Permalink Reply by Steve Cholerton on -
I wish I could change the way my passion for a project gets less once the challenges are met and I'm in the last quarter of the project - help screens, manuals etc :-(
-
Permalink Reply by Jonathan Wax on -
Hi,
The one thing I would change would be to stop "making up requirements" based on internal debate. I would much prefer to speak with a select group of our customers directly and ask them what they need. Then SHOW them some mocked-up interfaces so they can actually touch/feel the solution before we build any back-end code.
The amount of time saved by having a working mock-up that users approve up first before building any scaffolding would be huge!
Jonathan.
-
Permalink Reply by Neil Davidson on -
Jonathan,
What's stopping you from making that happen?
- Neil
Jonathan Wax said:Hi,
The one thing I would change would be to stop "making up requirements" based on internal debate. I would much prefer to speak with a select group of our customers directly and ask them what they need. Then SHOW them some mocked-up interfaces so they can actually touch/feel the solution before we build any back-end code.
The amount of time saved by having a working mock-up that users approve up first before building any scaffolding would be huge!
Jonathan.
-
Permalink Reply by Dawn Green on -
I had a conversation with one of my developers about rewriting a chunk of code. The code works, but it could be more elegant, and my developer would love the go-ahead for the rewrite.
I reminded him of our recent conversation about Collin Millerchip's post here on product managers being "messengers of the market" and "CEOs of the product". My developer's response was that developers need to take ownership of the code.
The product manager's requirement to meet business needs, and the developer's requirement to build great software are often at odds with each other. While giving ownership and free reign--as my developer suggested--would spark enthusiasm as developers got to apply new ideas to old, tired code, that same latitude costs time and money that affects profitability.
So, what would I change about the software process? I'd employ programmers who had to work as product managers, and I'd employ product managers who had to work as programmers. If both positions could understand the needs both internally and externally of the other, development would follow a process that made both sides happy.
-
Permalink Reply by Zviki Cohen on -
Take a narrow, short term, look at my software.
I'm used to playing the software architect. I always look far into the future and build my software in a way that is easy to maintain and extend. I look at simple problems as a single case of a much larger, generic challenge, and try to answer a broader question. This is great when working on major projects. But when writing small gadgets it just gets in the way. I end up spending too much time on design and on writing complex infrastructure that I may never use.
The solution is probably taking a middle way.
-
Permalink Reply by Mark Dalgarno on -
Tough question. I think one has to accept that there will always be something to change - if there isn't then you're not learning. Given this I'd like to be able to spend more time reflecting on how I write software and thinking about how I can do it better in the future.
What's stopping me? Sometimes there will be obvious improvements but in general I find it hard to place a value on such 'improvement' efforts and so things that have a clearer value usually get given more time.
-
Permalink Reply by Rachel Clements on -
For me, that would be getting excited about adding "just one new feature" in before releasing an app and then having the project deadline slide further and further away until all motivation has gone and I really don't want to be coding something which never seems to end.
I have recently made great steps to change this though.
Having watched Jason Fried's BoS conference video, this has really transformed the way I develop. I watched the video twice, made lots of notes and have pinned on my wall right in front of my view, his expression "optimize for now".
I am a changed developer as a result of this video and am only developing what needs to be done to get the first beta out and putting my excitement into the beta release, not the "extra, last-minute" features. As a result, projects are shorter, more achieveable and moving faster. I am a happier and more productive developer and yet my excitement and motivation have remained at a constant level.
-
Permalink Reply by Pavol Rovensky on -
I would change the prioritization and put more focus on the original customer's requirements. It sounds like a phrase however it seems to me that this part of the process is being still somehow underestimated and replaced with usual technology-architecture jargon.
Also I would operate in 2 phases - mocking up a quick prototype in order to understand the requirement fully and review it with customer (stakeholder) and then embarking on larger development effort.
-
Permalink Reply by Paco on -
I take "writing software" to mean the act of writing code.
In that regard, I would make sure we always have some of our best programmers involved with maintenance releases. I hate the old school thinking that says you put your newbie engineers on bug fix duty and keep your experienced guys working on new features.
New guys hate being "punished" just because they're new and not because of their skills. Plus they have the least knowledge of the code compared to anyone else on the team. And the guys who made the bugs don't apply their since-then experience to fix the code or to learn from their mistakes.
Not saying your best developer should be 100% committed to bug fixes. Just saying that they shouldn't get a free pass from maintenance work, and new guys shouldn't get stuck only fixing other peoples' mistakes.
-
Permalink Reply by Sohail Somani on -
Nothing. I'm good.
:-)
Well, realistically, outsourcing stuff that I don't do well like help documents.
-
Permalink Reply by Steven Farrell on -
We currently use Agile for software development. We are working now at changing the Product Development process to better align with the Agile methodology. There is very little information on developing a product road map, feature and requirements gathering, design and UX testing and getting all this to fit within an iteration plan. We are working closely with all aspects of the business to streamline our process to be able to react nimbly and intelligently to all the stimuli that affects the product.
I have come to realize this is no small task, but as we discover areas to improve, streamline tasks and engage development early I can clearly see the benefits.
Badge
© 2010 Created by Neil Davidson.
Powered by 
.
